Have API, Won't Travel

Vision Mobile has a blog post outlining the progression of APIs from Android into Google Play Services.

Been there, blogged that. :-)

Of course, Google isn’t the only one pursuing proprietary lock-in. Samsung’s mobile SDK is similarly proprietary, with licensing terms that can be best described as #epicfail. Amazon has theirs, and so on.

The key to any vendor offering an alternative to a leading proprietary solution is to convince developers to code to their alternative API. Unfortunately, so far, this seems to be matter of vendors taking the approach of “build an alternative API, and the world’s developers will beat a path to your door”.

This has not been a strong approach, historically.

On the whole, developers obey the laws of physics. One of Newton’s laws is that objects at rest remain at rest; similarly, developers at rest (with respect to a particular API caetgory) tend to remain at rest. Providing an alternative (say, Amazon’s maps instead of Google’s maps) on its own typically is insufficient.

Market share can help. Samsung will have an easier time convincing developers to code to Samsung-specific APIs than will, say, ARCHOS.

But if vendors want to offer a serious alternative to someone’s proprietary API, they need to make it easy for developers. Not only offer the carrot of market share, but remove the stick of “oy, that’s a lot of work”.

Face it: if developers need to write their own wrappers to work with N vendor-specific APIs for, say, in-app purchases, many developers will elect to set N=1 and only code to one such API (e.g., Google’s). If, however, developers can code to a single API and gain compatibility with N vendors’ worth of devices and market share, that will be more compelling.

The One Platform Foundation is trying this with Open In-App Billing. To a lesser extent, Amazon’s Simple Notification Service (SNS) can support Google’s GCM as well as their own equivalent, Apple’s solution, and others besides. And, of course, there are various ad network wrappers designed to isolate developers from network-specific integration woes.

But that sort of cross-vendor collaboration is going to be needed in general if vendors wish to break the stranglehold that popular proprietary APIs hold. We need the single mapping API, the Amazon SNS equivalent that can work beyond the Kindle Fire series, the single active stylus API (supporting Samsung’s S-Pen and anyone else going the active-stylus route), the local networking API (wrapping Samsung’s Chord, perhaps using Qualcomm’s AllJoyn or ZeroMQ as an alternative), etc.

Just because you have an API does not mean that developers will use it. It needs to be easy to use and worth the effort. The maximum possible “easy to use” and “worth the effort” is a cross-vendor solution that becomes the ecosystem’s default approach to solving the problem. Perhaps more vendors will pursue this path over time, or maybe some open source developers will “scratch their itch” and create some.

Anyone who wants a more open Android should want more open API options.