Anyone coming new to the mobile industry will immediately notice its love affair with the word 'open': Open operating systems; Open access; and of course Open source. Without exception, open is viewed as good and closed is bad, or even evil, depending on who¡Â&brkbar;s doing the evangelising. But the reality is that there's a tremendous amount of inconsistency in how the word 'open' is employed in the wireless industry and it is far from clear-cut that open is always good. It can sometimes be bad.
One ironic, and quite amusing misuse of the word open is in the context of handset operating systems. The likes of Windows Mobile, Symbian and Palm are frequently referred to as open OSes when they're not open at all. In fact, they're quite tightly closed. If you don't believe me, ask Microsoft or Symbian for their platform source code and count the seconds it takes for the laughter to begin.
Linux, on the other hand, is open source and a huge amount of interest and investment has now been poured into mobile Linux. The LiPS Forum, the LiMo Foundation, Purple Labs, a la Mobile, ACCESS, Celunite, MIZI Research, Open-Plug and TrollTech are just a few of the outfits providing mobile Linux specifications, base systems or complete Linux software stacks. The solutions coming out of these companies share two things in common: Firstly, from the perspectives of hardware integration and application execution, they are largely incompatible with each other; and secondly, the handset market share they currently enjoy is tiny most have no market share at all. These two factors are related.
True open source is great since innovations are continually fed back into the community which can tremendously turbo-charge the evolution of a platform. However, while Innovation is always welcome at the open source party, he usually travels with his best friend, Incompatibility, and Incompatibility is never without his buddy, Fragmentation. And as anyone who's tried organising a party knows, once fragmentation arrives, the party's over! This is the problem which mobile Linux is currently facing.
To stop fragmentation, a successful open source party needs an oversized bouncer at the door to block incompatibility. Having digested all the information released about the Linux-based Android, it is clear that Google intends to be such a bouncer for its nascent platform. This has led to many open source evangelists crying foul, arguing that, while Google is showing off its open source credentials, Android is being kept closed by stealth.
To a certain extent these pundits are correct, but the industry needs to wake up to the fact that true open source Linux is not the panacea it was once thought. The mobile market has finally reached a level of maturity where applications and services are now driving the next stage of growth. Operators are demanding that their handset portfolios consolidate around two or three platforms so that rich applications can be proliferated as widely across their subscriber base as possible, and the operators' OEM suppliers are having to respond. We are aware of some service providers seeing as much as 50% of their data traffic channelled to the MySpace site alone, and as such services evolve off the browser into widgets and dedicated apps, operators cannot afford to maintain a catalogue of application variants to match a disparate handset portfolio.
While the implementation of Java has improved considerably over the past couple years, it has never fulfilled its write-once-run-everywhere promise owing to the compatibility breaks caused whenever an operator or manufacturer introduced an innovation they wanted the bouncer as the Java party was clearly not doing his job.
Google understands the importance of consistency simply because if the PC market resembled today's handset industry, then Google would not be a $200 billion company and Larry and Sergey would probably still be finishing up their PhDs in their Stanford dorm room. We see Google preventing fragmentation of its Linux OS in two ways:
"¢ While the Android source code will be licensed under the Apache 2.0 license, allowing manufacturers to modify the source code without having to share their modifications, these companies must sign a compatibility pledge promising not to break interoperability. While it is unclear what action Google will take with vendors who do not comply, it should suffice to say that Google's pockets are deeper that even those of Nokia's and it could make things difficult for offenders.
"¢ Android will run Java applications, but Google will take the Java bytecode and convert it to its own virtual machine (VM) language: Dalvik. Dalvik is Google's proprietary virtual machine and has not released specifications for it. Many see this as Google¡Â&brkbar;s way of escaping Sun's Java royalties. No doubt, this is one motivation, but the true benefit is that now application developers only have a single VM which they need to test their code against.
Google has released the Android SDK and developers are likely to code natively for the platform. However, it is entirely possible that, if Dalvik proves to be a feature-rich and efficient VM, the large installed base of developers already well-versed in coding for Java will see Dalvik become Android's de facto application execution environment.
Google is not a handset OS company. Android is simply a means to an end the end being to create a vast new expanse of real estate which Google can beam its advertising inventory to. This demands a level of consistency and interpretability from Android so that, regardless of who implements the platform on whichever device, application compatibility is maintained. This means some tactics from Google which makes Android more closed than other mobile Linux offerings. But as all party-goers know, a good bouncer on the nightclub door making some heavy-handed decisions can make the party a whole lot better for everyone.