The ‘Big Reveal’ Release Approach in Mobile Linux – How Android and MeeGo Differ

A couple of weeks ago, I read through a somewhat heated email thread about the ‘Big Reveal’ mentality that Intel and Nokia were claimed to apply to the pending MeeGo 1.0 release. By coincidence, the timing overlapped with the excitement Google was stirring up for its 2.2 (Froyo) release of Android. Both events made me wonder about the value of a ‘big reveal’ approach in mobile open source stacks, and whether there might not be developments that occur within rapidly maturing software stacks that are native and systemic to the open source model, and that at the same time change the potential impact of ‘Big Reveal’ releases of either Android or MeeGo.

Don’t get me wrong, working for a commercial mobile Linux provider, I can see many benefits to having a big reveal release approach. It forces engineering, integration, testing and documentation discipline, it helps upstream users of the SW stack to rebase their commercial or otherwise public offering to the latest version and, last but not least, it also drives predictability in realizing (as opposed to prototyping) innovative technology. Now, both Android and MeeGo have organizations like Google, Intel and Nokia willing to heavily invest into a the structured development of innovation technologies, and the maintenance and the community development aspects of their respective open source stacks. However, if you look at the overall percentage of code that is maintained specifically for the purpose of creating the next big mobile software stack release versus code coming from general open source projects (OpenSSL etc…), it becomes clear that the vast majority of code comes from mature, well-maintained projects with their own ‘To-Do’ lists and functional update plans. Of course, one could argue that the percentage and importance of Google authored/sponsored code is much higher than for MeeGo, however, I believe this is really more a reflection of the different maturity of the respective stacks rather than a fundamental difference in approaching code development and community involvement. In other words, the difference is temporary.

Where I can see a difference in the approach between Android and MeeGo is that, under the guidance of the Linux Foundation, MeeGo release predictability is also being driven by initiatives like opening up the 1.1 development tree at the same time as releasing the 1.0 version. Google, by comparison, is still keeping its cards close to its chest when it comes to future functionality, only allowing close ecosystem partners such as major OEMs, operators and selected commercialization partners such as Wind River a limited level of visibility.

Where this difference matters is that it forces companies building Android and MeeGo devices to adopt a different planning model for their own mobile projects. For Android, one has to accept that the big reveal approach is ‘the way’ to rebase your own work to get the latest functionality. And Google has become quite adept at using its developer relationship cloud to create ‘Christmas present’ like eagerness to explore it. With MeeGo, on the other hand, the development model appears to be much more organic, like growing (watering, fertilizing) your own apple tree that gives you apples once a season (i.e. for a major release). 

For your planning requirements and independent of the OS itself, which approach works better for you?