Android forks: ho, hum

A friend sent me an article this week from InfoWorld entitled “Google Android's self-destruction derby begins.” The author seems to think it’s a big deal that the Android source code base is forking all over the place, although similar (and less apocalyptic) stories appeared last year in The Register and Business Week.

The reality is that forking is against the Free Software religion, and it’s also an inevitable outcome of any open source (or free software) license. People (or firms) make their own unique variants of the source code because they can: that was true 15 years ago with the BSD proliferation (BSDi, FreeBSD, NetBSD, OpenBSD), and it’s true with Linux today.

Forking is an organizational and economic issue, not a legal or technical one. The economic benefit of avoiding forks is to avoid re-inventing the wheel (on a daily basis for decades).

Forking long predates open source. In my first job out of college,I made it my mission to merge back all the source code forks in our proprietary code base (for our SIMSCRIPT II.5 compiler). The nominal goal was to facilitate maintenance and reduce incompatibilities, but the real reason was that merging changes across forks was tedious work, prone to errors,and that no one wanted to do.

However, the problem — then as now — is that maintaining a common code base requires surrendering control: if everyone is going to agree, then no one is going to get exactly what they want. Or — as in many open source projects — egalitarianism and meritocracy is ala Animal Farm: all contributors are created equal, but some are more equal than others. (What human endeavor is without politics? I can’t think of one.)

Android‘s cellphone licensees don’t want to surrender that control — and for that matter, neither does Google.

Thus (as InfoWorld notes) the Android handsets are shipping in a wide range of OS versions: 1.5, 1.6, 2.0 and 2.1. Part of this is that Android (like any new code base) is a rapidly moving target. The issue is compounded by the fact that Android handset makers all want to have their own custom user interfaces. (It seems as though Android is making the Symbian UI proliferation mistake all over again, which seems consistent with the high concentration of hubris in Mountain View).

In addition to the fragmentation of user experiences, the handset makers are having trouble updating their UIs to the latest Android OS — apparently due to (again not surprising) rapidly changing Android APIs. So in 2010 Sony Ericsson will be shipping an Xperia Mini based on Android 1.6, while the Nexus One (and its flashier half-sibling, the HTC Desire) will ship with Android 2.1

Of course, Google has also chosen to fork from the Linux kernel, because its own widespread code changes are both incompatible and (now) rejected by the Kernel team. If Google wanted to get along, it would have had to slowly and delicately negotiate with the Kernel honchos to come up with a consensus solution, but (not unrealistically) that it decide it would rather ship product in 2008 and 2009.

At some point, the Android APIs will stabilize (3.0? 4.0?) and the handset makers will be able to track the latest OS releases without major changes. They’ll still have their own GUIs — and for now Android will remain separate from the Linux code base — but things will be a little more efficient and a little less hectic.