From MeeGo to Tizen: the making of another software bubble

[Just a short 1.5 years from MeeGo’s birth, Intel dumps it to shift focus to a new platform, Tizen, in partnership with Samsung. Guest author Dave Neary discusses the underpinnings of Tizen and why both MeeGo and Tizen are software bubbles].

VisionMobile - From MeeGo to Tizen: A software bubble in the making

Eight months after Nokia embarrassed Intel by withdrawing support for the MeeGo project, Intel has followed suit. On 27th September, Intel and Samsung announced the birth of a new mobile platform called Tizen. After only 19 months, MeeGo has been left parentless, and appears to be on life support. Tizen is, in fact, a successor of the Samsung Linux Platform, a reference platform of the LiMo operator consortium, with some components taken from the MeeGo stack.

Given that LiMo and MeeGo have both failed to set the mobile computing world alight, and Android has a four year head start, can we expect better things from their offspring? What has changed with this announcement? Is this Intel’s last chance to have a stake in a credible smartphone platform? And what  should Samsung, Intel and the Linux Foundation do to give their new platform a fighting chance at success?

The Birth of Tizen

Last year, when reviewing the progress which MeeGo had made in its first few months, we reserved judgement on the project, on the grounds that it was “too early to be able to tell how the final product will compare to iOS or Android”, but we noted that there had been some growing pains between Nokia and Intel.

Those growing pains stretched to breaking point earlier this year, when Nokia finally gave up on MeeGo and turned to Windows Phone to revitalise its smartphone products. Intel was left looking for a heavyweight consumer device partner to come in and lend credibility to their claim that MeeGo was no longer a one-man show. Rumours that LG would be joining the project failed to materialise. Finally, Intel ran out of patience, and partnered with Samsung on a new platform, Tizen, to be based on SLP (Samsung Linux Platform), a platform which Samsung have previously provided to the LiMo Foundation to be used as a reference plaform for its members.

While the move has obviously been in the planning for months, Samsung were perhaps encouraged to partner with Intel on the back of the news that Google has acquired Motorola Mobility in August – a view supported by their recent settlement of an Android-related patent dispute with Microsoft. In addition, as LiMo members, most notably Vodafone also ran out of patience, SLP was left as a platform without a home.

MeeGo on Life Support

How does MeeGo fit into the big picture now? High profile participants like GENIVI, China Mobile, Asus and Acer have committed to shipping MeeGo devices. Will they be based on the unreleased MeeGo 1.3, or the previous 1.2 release? Or will these companies move en mass to Tizen?

Given the lack of reaction from partners like GENIVI, we suspect that the Tizen announcement caught these vendors unawares. Jerermiah Foster, a community manager working for one GENIVI member, informed me that his company would reuse MeeGo 1.2 in the short term, and while Tizen looked interesting, there were no current plans to move development to the platform. He also confirmed that he found out about Tizen through the project announcement, and not before.

In spite of vendors withdrawing their support, part of the community is banding together to salvage their work. After Nokia pulled out of MeeGo, community developers working on the MeeGo Handset UX banded together to continue work (with several Nokia engineers) in the MeeGo Handset Community Edition, aiming to provide MeeGo support for the Nokia N900, N950 and N9 devices. In spite of the Intel announcement of Tizen, these developers have vowed to continue the development of MeeGo on ARM, and released the MeeGo Handset Community Edition 1.3 at the end of September. The current plan proposed by these developers is to create a lightweight core distribution based on Qt, under the brandname “Mer” (“MeeGo Rebooted”), on which vendors can build custom user interfaces. The MeeGo Handset Community Edition will be the first consumer of Mer’s core operating system.

The MeeGo community mailing lists are full of developers wondering where they stand now. The announcement suggests that no software will be released from the Tizen project for another 6 months. According to Joel Clark, MeeGo IVI Program Manager, the MeeGo 1.3 release has been shelved, and only incremental updates to the previous 1.2 release can be expected until then. While the MeeGo community certainly has some enthusiastic community supporters, it is unlikely that any major vendors will adopt the community-supported Mer.

Ironically, the move away from MeeGo comes at a time of potential wins for the project. Nokia’s MeeGo-based N9 is finally shipping, and getting rave reviews. And continued demand for netbooks has fueled the launch of several MeeGo based netbook and tablet products, including the Asus EeePC X101, the Acer Iconia M500 and other devices from Samsung, Lenovo and Fujitsu.

Perhaps Intel ran out of patience just as the project was about to take off.

Tizen = SLP, with a pinch of MeeGo

Technically, Tizen is a successor of the Samsung Linux Platform, a reference platform of the LiMo operator consortium, with some components taken from the MeeGo stack. The project governance and infrastructure, however, will look a lot like MeeGo. According to Imad Sousou, the director of Intel’s Open Source Technology Center, and head of the MeeGo project: “in the new project, a lot of things will be the same as they were in the MeeGo project”.

We also know is that the primary APIs for 3rd party developers are targeting HTML5 and WAC environments. WAC stands for Wholesale Applications Community, a set of APIs for building and delivering rich HTML5 applications, based on APIs from JIL (Joint Innovation Labs) and BONDI (a platform specified by the now-defunct Open Mobile Terminal Platform, OMTP). The Enlightenment Foundation Libraries (EFL), are also set to be a key part of the platform. We can infer two things from this: Qt will be taking a back seat in Tizen, if it is part of the platform at all, and it appears that SLP will be the basis of the Tizen platform.

One thing which has not changed from MeeGo is the wide range of participants being targeted by the project. At the moment, the target audience can best be summarised as “everyone”. Tizen is aimed at platform developers, integrators, vendors, application developers, and mobile enthusiasts. That’s a very wide range of target audiences, each with different needs and expectations. Not knowing your target customer is a surefire way to throw money down the drain.

Challenges, challenges, challenges

Tizen’s main difficulties at this point can be broken into three groups.

First, there will inevitably be teething problems between the project founders. The fact that Samsung have not yet mentioned Tizen in any press releases or announcements, and the lack of new information coming from Intel representatives since the launch announcement, suggests that there may be some communication issues to be worked out in the relationship. In fact, at this point it looks like the active partners have not yet agreed on what will and will not go into the platform. Intel and Samsung will have to work hard to overcome the cultural dissonance which is inevitable given the very different corporate DNA.

On top of this, unless something changes soon, there could be a major mismatch between the reality of working with Tizen and the public positioning of the project. The project isn’t yet open for business, and when it is, it will only be useful for a small subset of its target market. If it were a new project, they might get away with it. But with the legacy of MeeGo, Moblin and Maemo, disappointing early adopters could be a very dangerous thing to do for Intel and Samsung. Getting the project governance and community dynamics right from the start is vital to learning from the mistakes of MeeGo and Moblin.

Beyond the community, there are question-marks over Tizen’s potential to make an impact in the industry. Google’s purchase of Motorola Mobility, not just a patent portfolio play, has created a disturbance in the force around the Android universe. Samsung does not want to find itself competing with Google at the same as they are dependent on them for their smartphone platform. This creates an opportunity for Tizen which it is too immature to exploit. For third party developers, concentrating on HTML5 is great. But will there be a demand for a native API also? And if so, will Tizen be capable of providing the kind of unified developer experience you get on iOS or Android?

It will be interesting to see if Intel and Samsung manage to get substantial support from other ARM vendors. As long as Intel are seen as the main custodians of the project, that seems unlikely. It will also be interesting to see the effect which Nokia’s first Windows Phone based devices, due to be announced at the end of October, will have on the project.

The main challenge for the Tizen partners will be getting devices to market. The key constituency for the change, vendors who were committed to MeeGo before, appear to have been neglected during the announcement. Intel and Samsung need vendors to adapt the platform to sell more chips, to give breadth to the ecosystem around the project, and to give credibility in the industry that this is not a party of two.

The Long Road Ahead

To succeed and make a space for itself in the mobile ecosystem, execution will need to be flawless on Tizen. If the internal bickering which dogged MeeGo rears its head again, if the initial release of the platform does not meet vendor and community expectations in terms of functionality and quality, or if there is an 18 month wait for well integrated finished products running Tizen, then the project may not have a second chance to make good.

Tizen seems set to be another victim of misaligned incentives across several industry partners. Samsung is bringing SLP to the “standards” table simply to find a new home for it, now that LiMo is winding down. Intel is seeking another marriage of convenience, trying to tempt a major OEM to ship significant x86 chip volumes.

– Dave

[Dave Neary is a regular columnist at VisionMobile writing on how companies can work more effectively with open source community projects. Dave is the founder of Neary Consulting and  has also been an active member of the GIMP, GNOME, OpenWengo, Maemo and MeeGo communities, with over 10 years of experience in open source community issues. He can be contacted at dave (at) neary-consulting (dot) com]

Open Source community building: a guide to getting it right

[Everyone – from carriers to OEMs – is busy building developer communities. But many have failed and more have seen disappointing results. Guest author Dave Neary looks at what lessons history can teach us on community building and the key DO’s and DON’Ts.]

Open Source community building: a guide to getting it right

Community development in open source software is not just for geeks in sandals nor for niche Linux companies any more. It’s mainstream and it’s here to stay.

The recent analysis of companies contributing code to the Linux kernel shows that large companies including Novell, IBM, Intel, Nokia and Texas Instruments are getting serious about engaging in community development. Organisations such as the LiMo Foundation are encouraging their members to work with community projects “upstream”, that is, with the community rather than in isolation,  to avoid missing out on millions of dollars worth of “unleveraged potential” (PDF link).

A diverse developer community is critically important to the long term viability of free and open source projects. And yet companies often have difficulty growing communities around their projects, or have trouble influencing the direction of the maintainers of community projects like the Linux kernel or GNOME. Sun Microsystems and AOL are prominent examples of companies which went full speed into community development, but were challenged (to say the least) in cultivating a mutually beneficial relationship with community developers. There are many more examples – but often we never even hear about companies who tentatively engage in community development, and retreat with their tail between their legs, writing off substantial investments in community development. Xara, for example, released part of their flagship software Xara Xtreme for Linux as open source in 2005, before silently dropping all investment in the community project in late 2006.

What can go wrong? What are the most common, and the most deadly errors which companies make in their community engagement strategies? And how can you avoid them? Avoiding these does not guarantee success, but failing to avoid them may be sufficient to guarantee failure.

Where to begin?
The easiest and gravest error that companies make is to sprint headlong into free/open source development with unrealistic expectations.

The history of free & open source software development is filled with stories of companies who are disappointed with their first experiences in community development. The technical director who does not understand why community projects do not accept features his team has spent months developing, or the management team that expects substantial contributions from outside the company to arrive overnight when they release software they’ve developed. Chris Grams once described the Tom Sawyer model of community engagement – companies who expect other people to do their job for them. Make sure you don’t fall into that trap.

Doing community software development well takes time, even when you get everything right. And there are a lot of things you can get wrong.

So where to begin? Before you start community development, you should have thought about what you want to get out of it. Is Open Source a way to grow the brand and broaden distribution of your product, with the goal of generating leads? Do you need to grow an ecosystem of developers building on top of your platform? Do you want to include an existing project into your product to reduce costs, but customise it to fit your needs? Each of these goals, and any of the other reasons people develop software in the open, require specific strategies and tools tailored to the situation to succeed. Indeed, how you measure success will change depending on your goals.

The two common situations company find themselves in are collaborating with an existing open source community, or growing a community around a piece of software that you are releasing.

Joining a community
When joining an existing community, building trust and reputation takes time. The first step to working productively with a community is to understand the structure of that community. Who are its leaders, what are its priorities? If the culture of a project does not align with your business objectives, that may affect your decision to engage with it in the first place.

If you find that you can work with the project, and that the general goals are aligned (or at least, not misaligned) with yours, then the hard work can start. For example, Hewlett-Packard backed Linux early, at the expense of promoting its own proprietary Unix, HPUX. Ten years on, HP now ships close to 40% of all Linux servers. In contrast, Sun Microsystems decided to create an independent community around Solaris in 2005, releasing OpenSolaris under an Open Source approved licence which is incompatible with the GPL (the licence of the Linux kernel). The Sun sponsored project failed to create a substantial independent developer community from its launch until the acquisition of Sun by Oracle and subsequent closing of the OpenSolaris project in 2010.

Once you make the decision to collaborate, and you have chosen the project you want to work with, the first and most important decision is who will work on the project. This consideration often does not get the attention it requires from top management. The engineers who will be working on the project on your behalf will be representing your company. It will be their job to build trust with project maintainers, navigate the project’s roadmap process to ensure that their work is accepted upstream, and ensure your business objectives are met.

The choice of the people who will work with the community is particularly important; as Stormy Peters, former Executive Director of the GNOME Foundation, once wrote, companies are not people. In other words, companies can never be members of a software development community, although their employees may. Companies can be valuable institutional partners for projects, but to quote the Beatles and Karl Fogel, money can’t buy you love (or community support).

So now you have some engineers working with the community. What next? Havoc Pennington wrote some excellent advice in 1999 for engineers working with community projects. The one-line summary might be: “when in Rome, do as the Romans do”.

Often communities will have documented their norms – many projects, including the Linux kernel and modules in the GNOME project, have “HACKING” files under source control documenting expectations for contributions, and mailing list policies. For most communities, these can be summarised as “go with the flow, don’t rock the boat”. Miguel de Icaza, founder of the GNOME project and vice president of developer platforms at Novell, has written an article explaining the reasoning behind these policies.

One temptation which you should avoid at all costs is to leverage the trust which one contributor has gained to channel contributions from others into the project. This will only promote Shy Developer Syndrome in your team.

By all means, have your senior community guy mentor others in the team and help them through the process, but avoid making that mentor a gatekeeper, shielding the rest of your team from the community. Attempting this will always backfire when your gatekeeper moves on or when the community finds out that he’s committing the work of others and circumventing community norms.

Growing a community
Looking at the second scenario; growing a community. If you do decide to release software under a free software OSI approved licence, your first choice will be whether to set the project up as a community project or not, and to what level.

Simon Phipps has written about the different types of communities which can grow around a free software project. He describes communities of core codevelopers, non-core developers who work on add-ons, integrators who distribute and configure the software, but don’t necessarily modify it, and finally users of the software. Each of these communities have different needs, and require different approaches.

If you want to grow a community around your project, there are a few best practices you should follow:

Control: If you opt for rules ensuring that you decide what code will be added to your product’s core, you will lose many of the benefits of community projects. Some examples of rules which come from a desire to maintain control are a requirement to assign copyright for all contributions to the core product to you, or ensuring that only employees can commit directly to the main branch of your core product. There are many good reasons to maintain ownership of the core, but this decision will severely handicap community contributions. This does not prevent you from developing other types of community, however, such as a community of add-on developers or integrators.

Barriers to entry: Barriers that contributors have to overcome can come in different shapes: using unusual tools, requiring convoluted processes for bug reporting, feature requests  or patch acceptation, or legal forms you may ask people to sign before contributing.

Tools and infrastructure: Ensure that you provide your users with the opportunity to distribute their work and connect with other users – whether this be through a forge for modules, or through the use of Gitorious of Bazaar for source control. Contributing in your project should be seen as a social experience.

Community processes: Create a just environment – no-one likes to be considered a second class citizen. Document processes for gaining access to key resources like bug moderator permissions, commit access to the master branch, or editor access for the project website.

Budget appropriately: Commit the appropriate resources – building a community takes time and effort, and that means investment – primarily of human resources.
Having one guy who is the community manager dealing with the community and a team of 10 developers behind the corporate walls isn’t going to cut it. As Josh Berkus of PostgreSQL said in his “How to Kill your community” presentation, if your nascent community feels neglected, it will just go away.

Launching a new project is like launching a new product – except that acquiring a new community developer takes much longer, and is much more difficult and costly than acquiring a new user. In the same way that companies track SAC for new product launches, tracking the Developer Acquisition Cost (DAC) for your project is a key metric in evaluating whether you are doing the right things to grow your community.

Developers have lots of projects to choose from, and they tend to gravitate towards projects where co-development is the norm. So you have to be thinking about the contributor experience, and the value proposition to external contributors, all the time.

A clear and compelling vision, with lots of opportunities to contribute, and low barriers to collaboration, can help reduce the acquisition cost of community contributors, and similarly reduce the cost of acquiring new users and paying customers.

Avoid common anti-patterns
If Best Practices are behaviours that should be adopted, community anti-patterns are best practices gone wrong. If the reasons behind a “best practice” are misunderstood, you can end up imitating behaviour without getting the desired result, much like the Pacific cargo cults, building airstrips and hoping that planes land. Like seasoning, adding too much can ruin the dish.

In general: when you see the following patterns happening, you should work to counter-act them, both in the communities you participate in, and in your corporate citizen behaviour within those projects. Each of these patterns are common and tempting, because they represent best practices applied in inappropriate circumstances. And each of them results in a net reduction of community health.

Some common anti-patterns you should avoid are:

1. Command & Control – communities are partnerships. Companies are used to controlling the products they work on. Attempting to transfer this control to a project when you want to grow a developer community will result in a lukewarm response from people who don’t want to be second class citizens. Similarly, engaging with a community project where you will have no control over decisions is challenging. Exchange control for influence.

2. Water cooler – when your team gets too much work done in private, your community will not understand your motives and priorities. By working on mailing lists or other publicly readable and archived forums, you allow people outside your company to get up to speed on how you work.

3. Bikeshed – A “bikeshed” discussion is a very long discussion to make a relatively minor decision. When you feel like the community is dragging you down, know when to move from talking to doing.

4. Black hole – It can be tempting to hire developers who have already gained reputation and skills in projects you build on. Beware when hiring developers from the community – it may be that the community will be worse off. Ensure that working in the community is part of the job description.

5. Cookie licker – Picture a child who has had enough cookies, but wants to save the last one for later. So they take it off the plate and lick it, to ensure no-one else will eat it. The same phenomenon exists for community projects – prominent community members reserve key features on the roadmap for themselves, potentially depriving others of good opportunities to contribute. Beware of over-committing, and leave space for community contributions in project roadmaps. Be clear on what you will and will not do.

Happy Community Gardening
Community software development can be a powerful accelerator of adoption and development for your products, and can be a hugely rewarding experience. Working with existing community projects can save you time and money, allowing you to get to market faster, with a better product, than is otherwise possible. The old dilemma of “build or buy” has definitively changed, to “build, buy or share”.

Whether you’re developing for Android, MeeGo , Linaro or Qt, understanding community development is important. After embracing open development practices, investing resources wisely, and growing your reputation over time, you can cultivate healthy give-and-take relationships, where everyone ends up a winner. The key to success is considering communities as partners in your product development.

By avoiding the common pitfalls, and making the appropriate investment of time and effort, you will reap the rewards. Like the gardener tending his plants, with the right raw materials, tools and resources, a thousand flowers will bloom.

– 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.]

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.]