From the MeeGo Conference: The State of MeeGo

60

Last week I was in San Francisco for MeeGoConf SF, the second large-scale MeeGo event. A lot has changed since the Dublin get-together last November — or at least that’s how it looks from the outside. Nokia (one of the co-founders of the project) hired on a new CEO from Microsoft, who announced in February that the Finnish phone maker would start using Microsoft’s Windows Phone 7 instead of its own smartphone operating systems. To a lot of mobile-phone-industry watchers, that looked like bad news for MeeGo, and it certainly disappointed a huge portion of Nokia’s MeeGo and Qt engineers, not to mention Maemo fans. But there is more to the MeeGo picture, which frames those events in a different light — as last week’s event showed.

Where we Compute

Figure 1The truth is handsets aren’t the whole story for MeeGo — they’re simply the current darling platform of the gadget blog set. In fact, they may not make up a significant portion of MeeGo’s revenue stream for device makers, considering that the margins on handsets get smaller and smaller all the time. The Linux Foundation’s Jim Zemlin raised that point in Monday’s keynote (note that the LF hosts Linux.com, in addition to curating MeeGo project resources, although it does not provide donations or engineering resources), which featured a cavalcade of industry-types and community hackers showing off the latest work in MeeGo’s 1.2 release.

What is a high-margin and ever-growing business is selling software services across non-PC computing devices. Everything from games to books to specialty content to cloud-based music and storage — and it depends on a user installing an app on some device with a screen, an OS, but no keyboard. Right now, most consumers in the US think of these services on phones, and to a lesser degree tablets. But they’re only thinking about today. It won’t be long before connected televisions are commonplace instead of a high-end novelty, kids are demanding games and social apps in the back seat of the minivan, and a slew of other appliances need to connect to something, somewhere. When the other non-PC platforms catch up to handsets in volume, what are they going to run under the hood?

Zemlin made a very strong case for Linux being the answer, with twenty minutes’ worth of slides and IDC analysis to substantiate it. Lower development cost, faster time-to-market, all the usual reasons any open source fan already knows. But buried deep within the statistics was an easy-to-overlook point that only MeeGo has going for it: when non-PC computing is pervasive, service vendors are not going to want to re-write their applications for every device.

That’s MeeGo’s secret weapon: because the core OS is the same, all applications are compatible across all of the deployment platforms. Right now, even the other embedded Linux vendors aren’t pursuing cross-device compatibility (see LiMo or Mobilinux, for example).

In contrast, there were MeeGo vendors from a wide variety of hardware angles on display in San Francisco. Lots of tablets from the likes of Intel and WeTab, plus set-top boxes, car navigation units (several already on the road in China, plus Nissan’s Chief Service Architect Tsuguo Nobe dropped by to announce the Japanese car-maker was adopting MeeGo), and even music consoles.

Without a doubt, Nokia’s decision to ship Windows Phone 7 on its next round of smartphones (it still has one MeeGo phone already nearing completion scheduled to be released this year) looks dour. It makes some people think the phone-maker didn’t find Linux and MeeGo up-to-snuff, and (worse), it keeps devices off the market. But the other MeeGo “verticals” don’t seem to be affected in the least.

Community

Of course, “the other verticals” essentially means OEMs: hardware device manufacturers. Most of them are interested in the MeeGo Core platform, with an eye towards customizing the interface to fit their own branding and “product differentiation” strategies. What is certainly more important to MeeGo’s viability is the health of the developer and contributor community, which makes for another interesting MeeGo Conf assessment.

By all reports, turnout at MeeGo Conf SF was higher than it was last fall in Dublin (an unofficial estimate pegged it at 850; it is trickier to count because as a free event there are always no-shows and people who register, grab a badge, then wander away). Partly the higher attendance reflects the more tech-centric location, but the really interesting factoid was that attendance was “significantly” up among the non-sponsor-attendees — meaning the community.

Close to half of the program was targeted at developers: the application framework, designing interfaces for multiple devices, the build and packaging systems, etc. Based on session attendance and conversations, the MeeGo developer community remains fired up about the platform. On the other hand, it is also frustrated at the lack of commercial MeeGo-based consumer products. Set-top boxes and car dashboard unit are good for the foundations of the project, but hardly generate buzz. Most of the community members I talked to were resigned to the fact that public perception of the project is simply going to stall until more devices reach users. They do seem to be using the out-of-the-spotlight time wisely, however, working on the QA process and infrastructure.

Are We There Yet?

But there are two areas where the project leadership does not seem to be getting its message out to the broader open source community. The first is the compatibility between MeeGo and desktop Linux. While the core set of APIs is smaller, by and large porting desktop applications to MeeGo is not difficult, thanks to the availability of Qt, GTK+, and the usual Linux stack underneath. Yet there remains a perception that MeeGo is a different beast, and most ports of desktop applications to the platform come from MeeGo community volunteers, not the upstream projects themselves.

The second message misfire surrounds the demo UX layers. Officially, the screenshots you see of tablet, handset, and even IVI MeeGo front-ends are “reference” designs: the project expects device makers to customize (or even custom-build) their own user interface layers. That concept is a difficult one for the outside world to grasp; you routinely see reviews and criticism of the look and feel or application offerings in the reference UXes, and some of them — netbook in particular — are actually in regular use. By leaving them in the bare-bones, not-quite-polished state that ship in the semi-annual releases, the public at large is getting a bad impression.

Figure 2The “reference only” concept is probably a relic of Nokia’s involvement; the phone maker steadfastly kept its own UI layer closed-source so that it could “differentiate” itself in the market. That’s a fair enough concern, but the rest of the project doesn’t need to let “unpolished” remain the public face of the MeeGo UX. Slicker UX releases can only help build excitement.

Luckily, there does seem to be some movement on that point; the N900 Developer Edition team is a volunteer squad building a more polished, usable MeeGo Handset experience for the Nokia N900 hardware. Better still, it is providing its changes back to the project. The community itself can build a slick UX layer.

Ultimately, as the hallway consensus indicated, MeeGo will probably continue to have a bit of a public perception issue as long as no mass-market phones and tablets are shipping for the gadget-hungry consumer sector. That’s too bad, but that’s life. It’s good to see that the community is taking it in stride, however, and actually committing its time towards improving the platform. Android and Apple both had to wait until after their devices launched to start building a developer ecosystem: MeeGo actually has an advantage because it already has one just waiting for the hardware to hit the shelf.