Getting Started with MeeGo

The MeeGo project is about to celebrate its first birthday, but there may still be Linux and open source developers who aren’t quite sure how it relates to other Linux-based distributions for tablets, netbooks, or phones — like Android, Chrome OS, or the netbook remixes of popular desktop distros. MeeGo takes a different approach, aiming to be a vendor-neutral Linux platform for a variety of devices. If you’re a developer, that is a key distinction, because it means it is easier to get started writing or porting apps to MeeGo, even digging in to the platform itself.

The Bird’s-Eye View

At its essence, MeeGo is a collaboratively-developed Linux OS designed for use on non-PC consumer computing devices. That means MeeGo is not intended to run on typical desktop systems or servers, which are already well-served by existing distros. But it is meant to replace the roll-your-own approach taken by most consumer electronics OEMs that want to build a product around Linux.

Moreover, the project aims to deliver a standardized Linux platform that OEMs can build real products around, but to keep that platform as close as possible to the upstream projects and “standard” Linux distributions. That simplifies the work for the product-maker, prevents fragmentation, and makes life easier for app developers as well.

The actual project was formed by merging two other Linux-for-devices projects that shared much of the same philosophy: Intel’s Moblin (which targeted netbooks), and Nokia’s Maemo (which targeted handheld devices like phones). Both used an “upstream first” development model, and they shared most of the same libraries and system software, so they joined forces. As a result, most of the lower-level components in a MeeGo system are the same regardless of whether it’s a netbook, handset, or a set-top-box: the kernel, X11, PulseAudio, BlueZ, Qt, Tracker, GStreamer, Telepathy, etc. The distinctly different use-cases are referred to as “user experiences” (UXes), and there active sub-projects for a handful of UXes: Netbooks, Handsets, Connected TVs, and In-Vehicle systems for cars.

Officially, the nonprofit Linux Foundation shepherds the project: it sets up working groups for each UX, hosts the infrastructure, sets the broad release schedules, and coordinates the community issues. But the actual coding on the MeeGo Core OS and the various UXes is done by volunteers and by developers who work for companies interested in making MeeGo-based products. Initially, a lot of the full-time MeeGo developers were from Intel’s Moblin and Nokia’s Maemo teams, but subsequently a large number of other companies (chip-makers, system builders, and software shops) have joined in as well.

The Code

The MeeGo project makes releases at approximately six-month intervals. Each release includes core OS components, and may include installable builds for several of the UXes, although which depends on the individual UX projects. For instance, the 1.0 release in May of 2010 included just the Netbook UX, while the 1.1 release that followed in October included stable releases for Netbook and Handset UXes.

Although the UX releases are installable, it is important to separate these releases from what an actual MeeGo-based product’s interface might look like. Each UX includes a “base implementation” of the user interface and core applications, usually sporting the familiar MeeGo branding and look-and-feel, but vendors like Nokia will generally customize the interface on their MeeGo-based products, possibly even adding or replacing applications.

The real importance to an official MeeGo release is compliance guarantee that accompanies the base OS. The project has a compliance program to test and verify that both hardware devices and software applications work with any given MeeGo release; that way app developers can be insured, for example, that their code will run equally well on a MeeGo-1.1-powered netbook regardless of whether it has an Intel or an AMD processor inside. The compliance specifications are hosted on the MeeGo wiki, as are further details on the process and the compliance tools used to check applications.

If you want to see MeeGo in action, the best place to start is with one of the installable images. MeeGo 1.1 builds are available for Atom-based netbooks, which is probably the simplest option for most developers, as well as Nokia N900 phone handsets and Atom-based in-vehicle-infotainment (IVI) devices. The downloads page on MeeGo.com holds links to the latest releases for each UX, plus the instructions for installing the releases on different hardware devices.

The process varies slightly from device to device, and as the project has grown more architectures are supported with each release — so be sure you read the instructions specific to your hardware. For example, although the Nokia N900 was the only supported Handset UX device when the 1.0 release was made, 1.1 includes builds for handsets using Intel’s Aava platform as well. Most Atom-based netbooks are supported by the Netbook UX release, and users without access to an Atom-based IVI system can also install the IVI UX on an Atom-powered netbook.

Getting Involved

Actual MeeGo development is done largely via upstream projects like the kernel, but you can browse through MeeGo-specific projects hosted at Gitorious.org. These include packages for subsystems like Bluetooth, cellular connectivity, and touch input, plus MeeGo-curated versions of key MeeGo Architecture components like security tools, package installation, and messaging that require closer integration work for compliance reasons. The repository also includes the base UX implementations, hardware-specific drivers, and support tools like SDK components and emulators.

If you are interested in getting involved with the MeeGo project itself — that is, contributing to the MeeGo code base, as opposed to making your own app run on MeeGo — you should start by reading the contribution guidelines. They explain how to submit feature requests and propose requirements, plus how to package and submit patches, how to fit your contribution into the release schedule at the best time, and how to escalate a patch request if your submission gets accidentally overlooked.