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)