MeeGo’s Community Woes: Improvement in 2011?

It’s a truism in open source that you can’t really persuade people to contribute to a project. You can, however, enable contributions and let people scratch their itch — or discourage contributions by putting or leaving obstacles between contributors and their work. MeeGo has not been doing such a good job of clearing out the obstacles between contributors and contribution.

When one open source developer complains about corporate influence on a project, it’s not necessarily a danger sign. It’s a big community full of a diverse range of opinions, and some folks are easily agitated or provoked to anger when things don’t go entirely their way — and generally do a good job of broadcasting their displeasure. So I take it with an enormous grain of salt when one developer complains about a project.

But in this case, the drumbeat is loud and coming from several projects. MeeGo has done a pretty good job of alienating most of the downstream projects that would re-package it and help MeeGo gain some traction in the developer and FOSS user community.

Quick disclaimer: I used to work for Novell as openSUSE community manager, one of the projects that has been having issues with MeeGo. (Which happened after I left Novell — MeeGo was announced in February of this year, I left Novell in January.) I also work with the Linux Foundation, which hosts MeeGo, as a contractor for Linux.com.

A Bad Beginning

First, Intel and Nokia stepped in it fairly badly when deciding to merge Maemo and Moblin. Not the decision itself, necessarily, but the way it was done. That is to say — Intel and Nokia decided to combine forces, but sort of forgot to consult with the vendors and community contributors to Moblin and Maemo beforehand. Maemo, in particular, had a fairly enthusiastic community building around it — that wasn’t really consulted about the plan to become MeeGo. Oops. Imagine for a moment that Fedora and openSUSE were to merge into FUSE, a distro that combines all the nifty stuff from both projects. If that bubbled up from the community and was driven by the community of contributors, then wonderful. If Red Hat and Novell just announced that it was going to happen by fiat, it would not go over well.

That’s pretty much what happened with MeeGo, but it wasn’t quite as apparent to the larger community because the Maemo and Moblin communities were much smaller. Things started off clumsily, and they don’t appear to be getting a lot better when it comes to community interaction.

Trademark Silliness

A big problem for MeeGo right now is its trademark policies, and the speed (or lack thereof) that they’ve responded to trademark requests. The first major respin of MeeGo by a downstream was Smeegol, put together by openSUSE folks — especially Andrew Wafaa, who has become rather disappointed at MeeGo’s handling of the situation. When MeeGo finally did respond, after Smeegol shipped, the answer was a big “no.”

The MeeGo folks are being hyper-cautious about their trademark, to the point of requesting that “meego” not even be used in package names:

We would ask you to move away from using {M,m}-e-e-{G,g}-o or any subset of those letters or sounds in that order, alone or in combination with other letters, words or marks that would tend to cause someone to make a reasonable connection of the reference with the MeeGo mark. We specifically discussed one possibility for illustration purposes — which is to use MG in the place of MeeGo. We do not think that a plain text MG, when used in reference to the code, as in a file or project or team name, would cause a reasonable person to be confused.

Upstream projects have been tetchy about trademarks before (which is one of the reasons we now have Debian’s IceWeasel) without too much fallout. Trademarks, are one of those pain in the rear legal issues that can usually be worked around if the corporate sponsors (or foundation) are willing to be community friendly.

MeeGo, on the other hand, is rapidly forging a reputation as being hard to work with and unwilling to do what it takes to facilitate packaging downstream. In other words, it seems to be the sort of project that is open source in name but not in practice. Real FOSS projects work to remove barriers to contribution and reuse, not to erect them. I’ve not seen much evidence of MeeGo clearing out barriers to reuse downstream.

Communication is Key

A big problem with MeeGo is communication, or lack thereof. The request that the openSUSE MeeGo-derived project not use “Smeegol” didn’t come until after they’d made and publicized their first release. When they did make the request, it did not seem particularly empathetic to the folks who’d spent their spare time packaging up the MeeGo derivative and trying to give MeeGo further exposure.

Let’s be very clear about this. The MeeGo folks were queried about use of the name and failed to respond after several queries. In general, questions, even on MeeGo lists, have often gone unanswered. It’s as if MeeGo doesn’t want repackaging to take place.

Then again, Nokia doesn’t seem to be all that clued in to the concept of promoting MeeGo at all. Consider this — when I was searching for info about MeeGo’s application ecosystem I found a link to “Nokia UI for Meego,” and got a blog post where the example video was removed because of a copyright claim from Nokia. Really? Heaven forbid that users might want to look at your UI in development before it’s released. Way to stomp on potential fans before they get too enthusiastic.

Developer Problems

But MeeGo hasn’t just alienated downstream repackaging, they’ve also managed to drive off a kernel contributor. Specifically, Greg Kroah-Hartman threw in the towel in late November after a lot of fruitless discussions with folks employed to work on MeeGo’s kernel for failing to submit significant changes upstream.

Apparently Nokia is also having problems with its traditional developer base as well — the devs are tired of waiting for devices and the OS to be done, already. This is not a slow-moving market.

Late, Late, Late to Market

The other problem with MeeGo isn’t the community end, it’s the pace that products are being developed at. Like ChromeOS, MeeGo is missing the holiday season — and netbook sales are falling off heavily. So by the time the first-generation MeeGo devices hit the market, they’re probably going to cruise into the market about the time that ChromeOS comes in and the iPad 2.0 is announced and presumably available. MeeGo will also be competing with Canonical in the netbook market and possibly tablet market at some point. That’s some stiff competition, and I’m not sure I’d put odds on MeeGo being the frontrunner.

Before you reach for the comment button, remember we’re talking about a mainstream market that doesn’t really give two penguin pellets that a product runs Linux. So no bonus for MeeGo being Linux-based or having FOSS licensing, even if the linuxdlsazine audience finds that compelling. The only metrics are going to be price, functionality, application availability, and whether the UI is something that grabs users’ fancy. What I’ve seen so far of MeeGo’s UI is not unattractive, but it’s not giving Apple a run for the money. It’s a wee bit too cartoonish for my tastes, and I suspect for a lot of the market.

No products have been introduced, so it’s up in the air as to the pricing — let’s assume that MeeGo devices are priced competitively. Applications are going to be in short supply out of the gate, and MeeGo is going to be competing for developer attention in a crowded market. On the mobile side, Android and iOS already have developers’ attention. On the netbook side… most netbooks already run Windows, so it’s hard to compete there. MeeGo will have Linux applications, of course, but there’s a gap for “consumer” apps.

It’s a shame that MeeGo as an upstream hasn’t done a better job courting the community. They could help with some of the application gap.

Now, it’s not like the folks running MeeGo have not tried to engage the community. The big meeting in Dublin was ostensibly designed to engage developers and bring the community together. But conferences alone don’t do the trick — it’s a daily slog, and even as big as the shindig was in Dublin, it’s a small percentage of the developers who have an interest in MeeGo.

Final Thoughts

Projects that have a single corporate sponsor have a rough enough time cooperating with a community. A project with two corporate motherships? I can imagine just how challenging it is trying to coordinate, and then adding community into the middle of that has to be a challenge. But no excuses — MeeGo needs to make some changes and embrace downstream participation.

A number of people in the community wanted to see MeeGo succeed as “the most open” mobile OS. (Android isn’t winning accolades from FOSS developers about its open processes, for good reasons.) These are folks who will drive the platform and make things happen, if you let them. If not, don’t bother with the window dressing. As long as Intel and Nokia comply with the licenses, there’s not much to complain about if they just push forward with their paid developers and contribute to the upstream projects as necessary to make the tools ready for what they need.

Even though I’ve criticized MeeGo here, it doesn’t mean I hope for the project to fail or that I think Intel and Nokia are being malicious. Quite the opposite, if Intel and Nokia could turn it around and do better at working with the community, MeeGo could be quite a good thing. But right now, MeeGo is doing a terrible job at reaching out to Debian, Fedora, openSUSE, and the rest of the downstream community — and I think they need these projects to do well. It is possible for MeeGo to work with those communities effectively if they make a real effort — let’s call it a resolution for 2011?