The MeeGo Progress Report: A+ or D-?

[Eight months after the announcement of the MeeGo  project by Intel and Nokia, guest author Dave Neary analyses the progress made to date in MeeGo Handset, and the project’s prospects for the future]

VisionMobile - The MeeGo progress report

The end of October saw the release of MeeGo 1.1, the second major milestone release of the platform since it burst onto the scenes in February 2010. The MeeGo project was born under the auspices of the Linux Foundation from a merging of Nokia’s Maemo platform, targeting smart phones, and Intel’s moblin platforms, aimed at netbooks.

[poll id=6]

The merger grew from a core idea: pick the best of breed components from both stacks, collaborate on the integration and testing of shared components, and standardise a number of open source UX (User eXperience) profiles, on which vendors could build and deploy complete commercial grade stacks. The initial UX profiles announced were netbook, smartphone, IVI (In-Vehicle Interface) and media center/TV.

Nokia and Intel have both made a major commitment to the platform, but critics say that the relationship is little more than a marriage of convenience. After all, Intel is a silicon vendor, betting heavily on the Atom-based Moorestown platform, and Nokia is a handset designer, largely shipping ARM-based devices.

Growing pains

The project has had some teething problems. Troubled Nokia has changed CEO, and the founding father of the Maemo project, Ari Jaaksi, has been among a number of high level software executives to leave the company, leading some to ask whether Nokia might have a change of heart about the platform. The first MeeGo device for Nokia, originally expected at the end of 2010, will now appear in 2011, according to recent comments from new CEO Stephen Elop, as Nokia strive to ensure a good first impression for its first MeeGo device.

There are some early public signs of friction in the working relationship of the stakeholders in the project, also.

The adoption of Qt as the primary toolkit for both platform and applications has met with resistance from Intel engineers, who acquired Clutter in 2008 and integrated it heavily into the netbook user interface, plus partners like Novell who developed versions of GTK+ applications like the Evolution email client and Banshee music player specifically for the netbook form factor.

Long-awaited MeeGo compliance specifications have resulted in drawn out and sometimes acrimonious debate.  Trademark guidelines have been a sticking point for community ports of the MeeGo netbook UX to Linux when these ports do not include required core components.

Related to the technical governance of the project, there is some uncertainty around the release process, and the means and criteria which will be used when considering the inclusion of new components. And there are some signs that the “all open, all the time” message at the project launch has been tempered by the reality of building a commercial device.

The Promise of Openness

Many of these issues are to be expected when merging two projects into one and pairing two very different animals. Every open source project has its own culture, and Moblin and Maemo are no different. Relationship capital which participants built up in the contributing projects must now be rebuilt within a broader group.

MeeGo has had some early successes. MeeGo 1.0, which included the Netbook UX and an early prerelease of the smartphone UX, was delivered in July, complete with the source code of a number of components which had previously been proprietary. Novell MeeGo has been shipping on a number of netbooks since then. The MeeGo wiki lists dozens of MeeGo-compatible devices. The inaugural MeeGo Conference is set to take place in Dublin, from the 15th to the 17th of November, and has sold out with over 600 registered attendees to date.

And there is no denying that the companies involved in the project are committed to it. With the recent rumours that the Symbian Foundation may be shutting up shop, Nokia has few choices of platform left for upcoming high-end devices. Announcing their updated software strategy during their quarterly results call this month, the company confirmed that they are fully committed to MeeGo as the only platform for high end devices from now on.

Clearly, there is a future for the project. The question is, how will MeeGo Handset hold up against the competition from the platforms with the most momentum in the market – iOS and Android, or the recently released Windows Mobile 7. Will a newly reinvigorated WebOS (with Ari Jaaksi at the helm) challenge it for the mantle of the exciting new upstart? In short, is it any good? And will operators, handset manufacturers, application developers and users adopt it?

User experience

Since we do not yet have a MeeGo handset device available, it is very difficult to accurately judge the user experience at this time. It is possible to install MeeGo on the Nokia N900 and use it as a phone, using Nokia’s proprietary drivers to enable the hardware, but a lot of basic functionality is missing at present. In my tests, the camera, GPS, battery indicator, network signal strength indicator and WiFi did not work correctly. Features which do work can be slow, or have stability issues. Basic functionality like reading contact details off a SIM card, or unlocking the SIM card on boot, are still missing.

A MeeGo device getting to the market will undoubtedly have pristine hardware integration using 3rd party drivers, and a considerable amount of fit-and-finish which the basic MeeGo stack does not yet have.

The MeeGo handset user experience is still in transition. Maemo 5, the platform’s predecessor, was created using GTK+ and Clutter, while the MeeGo user interface has been built from the ground up using Qt. By all accounts, there are still a number of stability and quality issues with the stack, which we can expect to be addressed in a release shipping on a device.

At this time, the MeeGo Handset UX is not intended for anyone but developers. It is too early to be able to tell how the final product will compare to iOS or Android.

The Developer story

At the time of its announcement, one of the key advantages held up to developers was the potential to use a single toolkit, Qt, to build native applications which will be portable across Windows, Linux and Symbian. Nokia has been investing heavily in RAD tools like Qt Quick to allow developers to get up and running quickly. In addition, their as-yet unavailable Web Run Time promises to allow developers to easily integrate web applications.

The developer tools are in development, and do not yet compare favourably with the equivalent Android offering, which includes easy tools for building, testing and deploying applications using Eclipse. In addition, since the project is still in relatively early stages, there is a marked lack of entry-level documentation to help developers get started.

It is still unclear what software distribution channels or app stores will be available for application developers on a MeeGo device. Ovi Store will be available on Nokia devices for commercial applications, and there may be a community distribution channel made available for community-built applications, but what form this channel might take, and to what extent it will integrate with the MeeGo user experience is still unclear. Presumably other handset manufacturers, should MeeGo gain wider adoption, will provide their own application stores, further fragmenting the application developer story.

MeeGo certification ensures that it will be possible to build applications which work across all vendors, but at this point the jury is still out on how useful “MeeGo Compliant” will be to application developers. There is a possibility of considerable fragmentation among non-core APIs when MeeGo devices from several vendors are available.

From the point of view of tools, documentation and software distribution channels, MeeGo is undoubtedly behind its primary competitors – but for such a young project, this is to be expected. The success of the project among application developers and the free software community will depend to a large extent on the project’s ability to fill these gaps and provide developers with an excellent development experience.

For platform developers, the story is much more encouraging. The source code to the entire MeeGo stack is available, and anyone can download images built daily. Images built for ARM and Intel Atom can be installed and tested on a range of developer devices, including the Nokia N900, TI’s BeagleBoard or PandaBoard, or the Aava Mobile developer kit.

On the other hand, there has been a tendency of the platform architects to reduce the range of hardware and software supported by the basic MeeGo stack. There is limited support for non-Intel x86 chipsets, and support for only a subset of ARM chips. Kernel modules have been aggressively trimmed, sometimes arbitrarily, to disable functionality such as NFS.

Community and governance

MeeGo development is all happening in a public git repository, most discussions are on public mailing lists, and there are a large number of experienced free software developers among the community development team, which is ensuring that any communication or transparency problems are identified and addressed swiftly. In the mobile platform development world, it is fair to say that MeeGo is second to none in terms of its open development model.

This contrasts sharply with Android which is primarily developed behind closed doors by Google, and iOS which is a completely proprietary platform. If there is a key differentiator for MeeGo in the hand-held market, this is it. It remains to be seen whether the open development model will be a selling point which will tip the balance when manufacturers are choosing a platform for a device.

The MeeGo community is made up of members of the Maemo and Moblin communities, and in the case of Maemo, there have been a number of contributors who have decided not to contribute to the MeeGo project. The move to MeeGo represents the third major change in the project in two years (after the move to GTK+/Clutter in Maemo 5 and the announcement that Qt would be the only supported application toolkit) and has left some shell-shocked.

The Moblin community, on the other hand, did not develop a large platform developer community, partly since the project did not offer a distribution channel for application developers. It seems like all those who were productively contributing to moblin have followed the project move to MeeGo.

OEMs and operator support

One of the key differentiators between traditional handset manufacturers and the young guns (iOS and Android) which have taken the market by storm, is that both Android and iOS have concentrated on the user and application developer experience to the detriment of their relationship with OEMs and operators. It is widely argued that Apple’s iPhone has reduced the role of the operator to that of a bandwidth and infrastructure provider. In turn Google takes a take-it-or-leave-it approach with handset manufacturers; unless manufacturers comply with Android’s compatibility definitions (CTS and CDD), they can’t have access to the Android trademark, Android Market’s 100,000+ application, Google Maps and several other closed source applications.

Nokia has a more traditional approach of putting handset manufacturers and network operators ahead of developers. This shows through in many of the architecture decisions in MeeGo. The platform has been built with operator and OEM customisation and integration in mind from the start.

A primary concern for OEMs with MeeGo is the time required to integrate the platform into a specific device and ship to market. With the time to market for Android handsets dropping to 4-5 months from project to production, it will be very hard for MeeGo to compete, even with the MeeGo 1.2 release, due in the first half of 2011.

Still a long way to go

It does not feel fair at this point to compare MeeGo, a project which came into being 8 months ago, with iOS or Android, but this is the yardstick which will be used when the first MeeGo smartphone comes on the market. The project has come a long way since its inception, in particular in working towards an open and transparent development model. There is still some way to go but improvements have been happening daily.

However, to succeed as a platform, the application developer story and the user experience are vital. There is a lot of work to be done in these areas for MeeGo to gain serious traction outside of the small community of Finnish handset designers. Nokia still has a long way to go.

– Dave

[Dave Neary is the docmaster at maemo.org and a long-standing member of the GNOME Foundation. He has worked in the IT industry for more than 10 years, leading software projects and organising open source communities,  He’s passionate about technology, and free software in particular.]

Is Android Evil?

[Is Android really open? Research Director Andreas Constantinou uncovers the many control points behind Android and explains why Android might be the most closed system in the history of open source].
The article is also available in Chinese and
Greek.

You thought Android was open? The Android governance model consists of an elaborate set of control points that allows Google to bundle its own services and control the exact software and hardware make-up on every handset. All this while touting the openness rhetoric that is founded on the Apache permissive license used in the Android SDK.

[updated in response to reader comments]: Whereas Android is completely open for the software developer ecosystem, it’s completely closed for the handset OEM (pre-load) ecosystem. There is no other platform which is so asymmetrical in terms of its governance structures.

Indeed, Google’s mobile platform is the smartest implementation of open source designed for driving commercial agendas. But before we dig into why, it’s worth discussing why Android’s success has very little to do with open source.

What makes Android tick
Despite early skepticism, Google’s Android operating system has been unequivocally supported by the mobile industry, including more network operators and handset manufacturers than one can count – with the stubborn exception of Nokia. Android managed to ramp from 1 handset model in 2008 to 50+ models announced for 2010 launch, leaving most industry observers in awe.

The Android success has nothing to do with open source; it’s owed to three key factors:

Apple. As strange as it might seem, Android owes much of its success to one of its arch-rivals. Let me explain. With the unprecedented success of the iPhone and the take-it-or-leave-it terms dictated by Apple to network operators, the carriers have been eagerly looking for cheaper alternatives; as such the tier-1 operators have been embarking on Android projects to produce iPhones for people who can’t afford the iPhone and more importantly, without forking out the 300EUR+ subsidy needed to remain competitive in an iPhone market.

Network operators/carriers around the world are eager to differentiate. Android provides the allure of a unified software platform supporting operator differentiation at a low cost (3 months instead of 12+ months offered by SavaJe, which was also aimed at the MNO customisation market). For larger operators with a software strategy, Android also presents a safe investment, as the mainstream option for bringing down the cost of smartphones. That’s why most Android handset projects are backed by a commercial bipoles of operator + OEM deals, with purchase commitments and NRE fees coming from the operator.

Qualcomm. The $10B chipset vendor has been paramount to Android’s ramp up; manufacturers can take Qualcomm’s hardware reference design which is pre-integrated with Android and can go to market within an estimated 9-12 months (down from 16 months for the Motorola Cliq handset and 24+ months for the HTC G1). Besides Qualcomm we should also mention TI’s OMAP3 platform (on which Moto Droid is based) and ST Ericsson and Broadcom who are ramping up to offer chipsets with out-of-the-box support for Android.

In other words, in an Android handset, most of the OEM budget goes into differentiation; compare that to Symbian where most of the OEM budget goes into baseporting (radio and functional integration of hardware) due to historical choices made by Symbian in 2001. All-in-all, Android allows OEMs to reduce their R&D budgets and invest in differentiation, which is mana from heaven to manufacturers.

We should also not forget the ‘free factor’ (technically zero per-unit royalties for the public SDK) which stirred the emotional hype around Android handsets.

All in all, the ‘open source’ marketing moniker has been very successful at triggering major industry disruption – incl. Nokia ‘s acquisition of Symbian and the derailment of Windows Mobile. Perhaps more importantly, the openness rhetoric and the Google aura has attracted thousands of developers on the platform, at a time when the money equation is sub-par; consider that – compared to the Apple devices – Android handsets are around 9x less in volume and paid-for apps are available in 6x fewer countries.

Behind the Open Source facade
What’s even more fascinating is how closed Android is, despite Google’s old do-no-evil don’t be evil mantra and the permissive Apache 2 license which Android SDK source code is under. Paraphrasing a famous line from Henry Ford’s book on the Model-T, anyone can have Android in their own colour as long as it’s black. Android is the best example of how a company can use open source to build up interest and community participation, while running a very tight commercial model. [updated in response to reader comments:] Again I ‘ll emphasize that the closed aspects of Android apply to the handset OEM (pre-load) ecosystem, not the software developer (post-load) ecosystem (see the comments section for a deep dive into pre-load vs post-load].

How does Google control what services, software and hardware ships in Android handsets? The search giant has built an elaborate system of control points around Android handsets.

To dig deeper we spent two months talking to industry sources close to Android commercials – and the reality has been startling. From a high level, Google uses 8 control points to manage the make-up of Android handsets:

1. Private branches. There are multiple, private codelines available to selected partners (typically the OEM working on an Android project) on a need-to-know basis only. The private codelines are an estimated 6+ months ahead of the public SDK and therefore essential for an OEM to stay competitive. The main motivation for the public SDK and source code is to introduce the latest features (those stemming from private branches) into third party apps.

2.  Closed review process. All code reviewers work for Google, meaning that Google is the only authority that can accept or reject a code submission from the community. There is also a rampant NIH (not invented here) culture inside Google that assumes code written by Googlers is second to none. Ask anyone who’s tried to contribute a patch to Android and you hear the same story: very few contributions get in and often no reason is offered on rejection.

3. Speed of evolution. Google innovates the Android platform at a speed that’s unprecedented for the mobile industry, releasing 4 major updates (1.6  to 2.1) in 18 months. OEMs wanting to build on Android have no choice but to stay close to Google so as not to lose on new features/bug fixes released. The Nexus One, Motorola Droid, HTC G1 and other Experience handsets serve the purpose of innovation testbeds for Google.

4. Incomplete software. The public SDK source code is by no means sufficient to build a handset. Key building blocks missing are radio integration, international language packs, operator packs – and of course Google’s closed source apps like Market, Gmail and GTalk. There are a few custom ROM builders with a full Android stack like the Cyanogen distribution, but these use binaries that are not licensed for distribution in commercial handsets.

5. Gated developer community. Android Market is the exclusive distribution and discovery channel for the 40,000+ apps created by developers; and is available to phone manufacturers on separate agreement. This is one of the strongest control points as no OEM would dare produce a handset that doesn’t tap into the Android Market (perhaps with the exception of DECT phones, picture frames, in-car terminals or other exotic uses of Android). However, one should acknowledge that Android’s acceptance process for Market apps is liberal as it gets – and the complete antithesis of the Apple vetting process for apps.

6. Anti-fragmentation agreement. Little is known about the anti-fragmentation agreement signed by OHA members but we understand it’s a commitment to not release handsets which are not CTS compliant (more on CTS later).

7. Private roadmap. The visibility offered into Android’s roadmap is pathetic. At the time of writing, the roadmap published publicly is a year out of date (Q1 2009). To get a sneak peak into the private roadmap you need Google’s blessing.

8. Android trademark. Google holds the trademark to the Android name; as a manufacturer you can only leverage on the Android branding with approval from Google, much like how you need Sun’s approval to claim your handset is Java-powered.

In short, it’s either the Google way or the highway. If you want to branch off Android you ‘re completely on your own and you need resources of the size of China Mobile (see their OMS effort) to make it viable (hint: China Mobile is the biggest network operator bar none).

The Open Handset Alliance is another myth; since Google managed to attract sufficient industry interest in 2008, the OHA is simply a set of signatures with membership serving only as a VIP Club badge.

Another big chapter in the Android saga is the CTS (compatibility test suite) which is the formal testing process by which a handset passes Google requirements. According to our sources, CTS extends significantly beyond API compliance, and into performance testing, hardware features, device design, UI specs and bundled services. CTS is based on the principle of ensuring baseline compliance, so it’s ok to add features, but it’s not ok to detract; compare this with Apple’s no-Flash policy. Note that beyond CTS compliance, there are additional commercial licensing agreements that OEMs have to sign for Google services and private line access.

CTS hampers Android’s progress as well, as it precludes OEMs from creating stripped-down versions of Android that would fit on mass-market phones – those shipping in the 10s of millions. CTS – and forward compatibility to the pool of 40,000+ apps – is Google’s main challenge for hitting a 2-digit market share in the smartphone market. These restrictions – and frienemy relationship between Google and its OEM partners – have stirred up discussions of an ‘Android foundation‘ within OEM circles

The Google Endgame
With Android, Google aims to deliver a consistent platform to its own revenue-generating services. For now, this is the ad business. But in the future, Google is aiming at voice (reaching the billions who don’t have a data connection) and Checkout (i.e. becoming the Visa of mobile).

Yet whatever the endgame, it’s worth realising that [from the manufacturer perspective] Android is no more open – and no less closed – than [licensable operating systems like] Windows Mobile, Apple OSX or PalmOS, Symbian and BREW; it’s the smartest implementation of open source aimed at driving commercial agendas. Android is much less about the do-no-evil rhetoric that the PR spinners in Mountain View would like us to think.

[Updated in response to readers’ comments:] so, is Android evil? No, it isn’t. It has done no harm – quite the contrary, Android has boosted the level of innovation on mobile software. The point of the article is not to vilify Google or concoct visions of Darth Vader; but to balance the level of openness hysteria with a reality check on the commercial dynamics of mobile open source.

– Andreas
you should follow me on twitter: @andreascon

[we are running on-site business workshops for companies who want to understand the commercials behind Android and OHA. Contact us if you ‘re interested. Or, if you are a mobile developer, voice out your views on Android and other mobile platforms in the biggest mobile developer survey to date. Join in at visionmobile.com/developers]