Fighting Closed with Open
An article that is making the rounds is Ars Technica’s “Neither Microsoft, Nokia, nor anyone else should fork Android. It’s unforkable.”. The author (Peter Bright) early on states:
Google has worked to make Android functionally unforkable, with no practical way to simultaneously fork the platform and take advantage of its related strengths: abundant developers, and abundant applications.
There is a practical solution, one that can beat Google at its own closed-source game. However, it requires business executives who aren’t control freaks, which unfortunately makes it improbable.
Mr. Bright’s argument is that Android is only partly open source. Google Play Services is closed source, and Google certainly pushes this set of APIs. Only licensees have legitimate access to Play Services, and apps that require Play Services can therefore only run on licensed devices.
His conclusion, therefore, is:
The only way to solve the application issue is to be not merely an AOSP platform but a [Play Services] platform.
Nope.
The only way to solve the application issue is to get developers to become less dependent on Play Services. And, IMHO, the only viable way to do that is for other vendors to collaborate and build up a competing suite of open APIs, ones that can plug into Play Services or into alternative implementations.
Mr. Bright posits that creating a replacement for Play Services is a lot of work, and he is correct. However, there are already replacements for much of it, whether in the open source arena (e.g., Open Street Map) or in the commercial realm (e.g., Amazon’s various replacements for use on the Kindle Fire series).
The problem isn’t a lack of alternatives. It’s a lack of a compelling reason for many developers to bother with those alternatives.
Google has done a reasonable job of ticking off the two major boxes for considering an API:
-
Making it fairly easy to adopt (e.g., from educational, technical, licensing, and operational standpoints)
-
Delivering a nice-sized audience for the results
Having an umbrella API, that plugs into Play Services or alternatives, can only expand the audience. Hence, if it becomes easy to adopt, sensible developers will certainly consider it.
The problem is that vendors like Amazon are focused on trying to be Google and have their own lock-in. Some percentage of Android developers will adopt such firms’ proprietary APIs, either for dedicated apps for such firms’ devices, or slogging through multiple implementations. But a lot of developers will not bother, just as a lot of developers do not bother with the Amazon AppStore for Android — and I’ve tried for years to get developers to think about distribution beyond the Play Store. If it isn’t easy, and it isn’t huge, it isn’t on most developers’ radar.
There’s nothing stopping some consortium, or a nicely-backed open source initiative, from taking a page from the same playbook, and aiming to give Android developers a reason to switch to a higher API that offers a larger audience. This would spread the effort amongst multiple interested parties, from major vendors (Amazon) and major ROM modders (Cyanogen, Inc.) to the countless firms who offer something in the Play Services sphere and would relish the opportunity to plug into a common API and not get trampled by all the elephants.
This still will not be easy. And, it would eliminate these vendors’ ability to achieve lock-in in the same areas that Play Services covers. Hence, I have no idea if there is a critical mass of players who would take on such a task. And it will take patience and time, once something is ready, to educate and convince developers to migrate to such a solution. But an open set of APIs would weaken Google’s lock-in ability with Play Services, and I would think that this might be an objective of some of these firms.
If you want to fight the closed Play Services, building fragmented closed alternatives is an unlikely solution. Instead, fight closed with open.
