Lame and inelegant. This was our reaction when we discovered that a launch partner of OpenUDID, Crashlytics, decided to create an alternative to the UDID called SecureUDID. It’s not so much about the code and the product, but rather the process and the lack of disclosure. The issue here is really about Open Source project netiquette.

Back to the origins

When Apple announced the deprecation of the UDID almost a year ago, we were amongst the first to set time aside and start building an alternative. We wanted it to be open source and Appsfire would support it.

It was announced publicly and it instantly attracted the interest of hundreds of developers, including some nice brand names. Crashlytics was one of them – they wanted to contribute and also be part of the launch operation PR. We announced then publicly that OpenUDID was supported by a few organizations including Crashlytics.

Nothing wrong up to that point. Or so we thought!

“New” code suddenly appears

Yesterday Crashlytics announced SecureUDID on Techcrunch, claiming it was built from the ground up to address an app-specific ID. This came as a surprise to us.

Not because those guys have decided to do something different, but because of the way they decided to do it.

They declared on Techcrunch that they felt the project was inadequate:

“When Apple announced its intentions to deprecate the UDID, everyone began scrambling for solutions. AppsFire was one of the first companies to launch an alternative – an open source solution called OpenUDID. In fact, Crashlytics’ own Sam Robbins was a contributor to that initiative. But over time, the company grew to believe that the OpenUDID solution was not ideal. ” TechCrunch

It’s weird for a “contributor” (one who contributed ta very minor part of the code…see below) who reached out to us and became a launch partner to then go silent and never share his vision or concern about the project. Isn’t it?

When we reached out to them on Github, they explained they had to rebuild the code from the ground up for their purpose. Let’s assume this is accurate. But then they suggested to “merge” both projects.

Wait, “merge”? If the project required a different architecture, why do they now believe the two projects can be merged? In addition, if this is the case, why not just contribute to OpenUDID in the first place?

Looking at their site, there is absolutely no reference to OpenUDID as a source of inspiration or architecture in anyway. And yet they use the core mechanisms “pioneered” by the OpenUDID code. Worse, they peg their initiative against OpenUDID claiming that it does more, while in fact, it does less (i.e. it does NOT allow cross-app id sharing, which was a fundamental use case for the original UDID and certainly the main driver to create OpenUDID). In short, their effort and marketing clearly piggybacks, adds confusion and misleading arguments to the developer community and then amplifies it with top-tier blogs.

Here is the reality

SecureUDID actually serves a different purpose than OpenUDID: it helps developers create a unique and persistent UDID, shared within the same namespace (app or developer): ok for analytics. What SecureUDID doesn’t do is let this token be accessed by a 3rd party app: useless for advertising.

Let’s be clear: the code looks decent. There is little to say about it, nor any rocket science to it. Except that it uses encryption which may require to tick that tick box when submitting to Apple…

What’s lame about it all is how Crashlytics has managed the approach: Not informing us about their intention or vision, using part of the mechanisms that were in the original code (UIpasteboard, Opt-out) and not attributing any credit, but worse not even communicating the limitation of what their code does. Here is a visual of how the landscape looks like today:


So let’s summarize the situation here

  1. Sam Robbins, a Crashlytics developer/employee was a one-time contributor, added a few compile flags to make it work on Mac OS X (not a key platform)
  2. Crashlytics requested explicitly that “their” contribution be mentioned
  3. Crashlytics, quoted on October 18th 2012: “We’re big supporters of openUDID here and we’d love to be a part of your press release [..] our goal is to help […] including contributing to openUDID and making it better”
  4. SecureUDID borrows all clever mechanisms from OpenUDID: UIPasteboard for persistence, Opt-Out
  5. SecureUDID does not solve the inter-app/ad-network UDID replacement need, but rather creates an cloacked UDID for each developer
  6. SecureUDID uses CommonCrypto lib and AES-128  which may require to declare that the app uses encryption (this creates additional friction during app submission)
  7. SecureUDID is NOT an alternative to OpenUDID, it serves a different purpose. In some ways, it does NOT compete (see point #5)
Open Source projects should be about dialog, contribution, honesty and transparency. It’s about code and also about an implied code of conduct: the netiquette.
We’re happy to see this SecureUDID initiative (after all, OpenUDID needs to be perfected).
But we’re disappointed to see how this was brought about and promoted and felt compelled to inform those interested of the situation (many, trust us!).
  • Rangel Spasov

    Well said.

  • Guest

    “Lame and inelegant” best describes your attitude. Someone who previously worked with you in a “very minor” way decides to go off in a different direction, and you’re upset because he didn’t first clear it with you.

    I can understand being disappointed at waking up to find that your project may no longer be the go-to solution for iOS developers. I suppose I can understand being irked that some of your “clever” ideas have been used, although I always thought sharing good ideas was one of the goals of open source software.

    Instead of whining publicly, why not redouble your efforts and make OpenUDID better? Why not offer developers — or better, end users — a choice of providing a single UDID that works for advertising purposes or a per-app UDID that just makes apps work better? Users could choose “no tracking,” “per-app tracking,” and “per-device tracking.” Indeed, if Crashlytics has offered to merge the projects, you could probably accomplish all this very quickly.

    • OurielOhayon

      Dear …

      Yes OpenUDID is built in a framework to improved by the day by the community. We welcome any other initiative as long as they describe their limitations…

  • Nano

     Uriel you guys project very bad energy, your cowboy attitude will become your setback.

  • Fabien

    I think you should have some other cases like this one… you have 39 forks of your project on github. For an not so active project, that’s a lot ! Potentialy, each one can be a new competitor/solution. I don’t know how it works about code lisence on the social coding sphere…   

    • OurielOhayon

      no we won’t. this case is very specific to a initiatl contributor who asked to be associated as a founding member of the code. We have now lots of contributors but none of them have asked to be associated in that manner, including in the PR. this is an open source project. Any one is free to do whatever he wants. But that case we describe here is only applicable here.

      • Fabien

        I hope so ;-)