First Look: OpenMoko’s Linux-based open smartphone platform

Penguin calls

Last Friday, OpenMoko launched its highly anticipated FreeRunner smartphone, a Linux-based handset that’s completely open in both hardware and software, and is designed to encourage third-party modification and customization. Although the FreeRunner’s software platform is still incomplete, the device has attracted considerable attention from mobile software developers and Linux enthusiasts.

The FreeRunner handset is obviously a powerful tool for prototyping mobile software, but it isn’t clear yet whether it’s also ready for adoption as a personal smartphone. We won’t have a conclusive answer until we get a handset to test, but we decided to take an early look at the OpenMoko software platform to get a glimpse of what it offers at launch.

In many ways, OpenMoko’s platform strategy mirrors the diversity of the Linux desktop software ecosystem. There are a multitude of parallel options with many layers and varying degrees of overlap. This provides end users with an enormous amount of flexibility, but it also creates a lot of complexity. The choices are difficult to navigate, and the lack of a cohesive direction contributes to fragmentation and redundancy. OpenMoko’s potential for success will be heavily predicated on the ability to turn choice and diversity into an asset rather than an impediment.

There are currently three separate software stacks that are available for OpenMoko handsets. The original OpenMoko software environment was built on top of GNOME Mobile and Embedded technologies including the GTK+ toolkit. As the FreeRunner launch date approached and the development priorities began to shift towards a stronger emphasis on mainstream consumer adoption, OpenMoko reevaluated its approach and decided to build a new stack on top of Trolltech’s proven Qtopia mobile environment. The third stack, which will implement the FreeSmartphone.org APIs, is part of a long-term framework initiative that OpenMoko hopes will eventually ameliorate the problems created by fragmentation and redundancy while still offering developers a full range of choices.

Because the FreeRunner is a completely open device, users will be able to choose which platform they want to use. They will also be able to adopt any third-party software platforms that emerge in the future. We have already seen an impressive variety of Linux desktop environments and graphical shells ported to Nokia’s Internet Tablet devices, so it is likely that we will see similar innovation on OpenMoko’s handsets. Indeed, developers of the KDE desktop environment have already started working on experimental OpenMoko ports.
OpenMoko’s GTK-based stack

The GTK-based OpenMoko stack, which is referred to as om2007.2, offers a moderately conventional finger-oriented interface and a variety of standard productivity, Internet, and entertainment applications. It is a reasonably intuitive environment and it adheres to a very high level of visual consistency. There are a lot of similarities between om2007.2 and Nokia’s Maemo platform—both are based on GTK+ and use OpenedHand’s lightweight Matchbox window manager. OpenedHand also developed several other important pieces of the om2007.2 stack, including the personal information management suite, which is called Pimlico.

The om2007.2 web browser uses Apple’s open source WebKit rendering engine. As many readers are already aware, I’m a big fan of the GTK+ WebKit port and I’ve been very impressed with its small footprint and excellent support for standards.

In addition to all of the standard applications one would expect to see on a smartphone, a terminal application that supports entering commands with an on-screen keyboard is also included. Users have full root access to a BusyBox shell with all of the standard scripting tools like sed and awk. The stack also comes with a multitude of games, a media player application, a calculator, a package manager for installing additional software, and other tools.

Booting om2007.2

The home screen

The dialer interface

OpenMoko’s WebKit-based browser

The application launcher

The media player

The terminal utility

To build new applications for om2007.2, developers will need to set up a cross-compilation toolchain on a Linux system. The OpenMoko wiki offers detailed instructions for this process and also describes how to compile and package a program. Developers who want to go further and modify the underlying platform can use the OpenEmbeded infrastructure, which provides an elaborate build engine for generating package sets.

The platform exposes phone capabilities through the gsmd daemon, which sits between the GSM modem and userspace applications. Instructions can be sent to the daemon through standard UNIX sockets. The libgsmd library is an abstraction layer that wraps the instruction protocol with a simple API. There is also a gsmd command shell tool for testing and debugging that gives the user interactive control over the daemon. A wide range of functionality is accessible through the daemon, including the ability to dial and answer calls, toggle the phone’s vibrator, detect signal strength, read and send SMS messages, and retrieve the phone’s battery status.

For rapid prototyping and avoiding the hassle of having to set up a compiler toolchain, developers can use Python to create OpenMoko applications. Python isn’t officially supported, but the interpreter is available from the main repositories and GTK+ bindings are available from third-party repositories. The Python library for interfacing with gsmd isn’t there yet, but there are already several useful Python-based utilities for OpenMoko that send instructions to the daemon by using the command line gsmd control utility. These include the SettingsGUI tool and the SMSTool.
The ASU stack

The om2007.2 platform offers a pretty strong user experience, but some of the limitations of GTK+ and the incompleteness of gsmd compelled the OpenMoko developers to pursue a change of direction. In order to provide more robust phone support for end users, the developers decided to adopt Trolltech’s Qtopia platform, which is used on several mainstream consumer electronics devices including the Sony Mylo. Qtopia provides a complete phone server component that is more stable and reliable than gsmd.

When OpenMoko adopted Qtopia, the developers began working on a new platform that became known as the April Software Update (ASU). The ASU uses the X11 port of Qtopia so that it can still support existing GTK-based applications. The ASU also uses some components of Enlightenment’s E17 desktop environment. It includes a visually sophisticated application launcher interface called Illume that takes full advantage of touchscreen interaction and is designed with the Enlightenment Foundation Libraries. Although the artwork and graphics quality in the interface need a lot of work, the interaction paradigm is quite innovative.

Booting the ASU platform

The Illume launcher with its default icon layout

The Illume launcher with its unique slider layout

ASU’s SMS messaging tool

The ASU phone dialer

An ASU clock utility

Adding a contact with the ASU addressbook

A mapping demo for ASU

The biggest downside of the ASU is that software applications designed to integrate with om2007.2 and gsmd won’t fully integrate with the ASU environment. Applications written with GTK+ will run on the ASU, but developers will have to use Qt and C++ for proper integration. The biggest advantage of the ASU is that it offers a much more stable phone server, which means that it will eventually be better suited for a mainstream user audience. Unfortunately, the ASU wasn’t complete or polished enough for distribution with the FreeRunner. Even though the ASU is the current focus of OpenMoko development, the FreeRunner still shipped with the om2007.2 platform.
The FSO stack

The availability of two very different platforms that both require a different toolkit for proper integration will fragment the OpenMoko application ecosystem. Third-party software that leverages the underlying functionality of the phone will have to be written for one or the other. This is one of several problems that OpenMoko hopes to eventually solve with its framework initiative, which implements the FreeSmartphone.org specification. The platform being built around the framework initiative, which is called FSO, will supply a standardized D-Bus API for providing high-level access to the GSM functionality and other phone-related parts of the stack. This will make it possible for applications written in any toolkit, with any programming language that has D-Bus bindings, to fully integrate with the system.

The FSO is still in very early stages of development and isn’t really ready for regular users yet, but developers say that the phone server in the FSO stack is already better than gsmd or the Qtopia phone server. At the present time, the FSO doesn’t really have much going on at the application level, and it uses a simple placeholder framework called Zhone to provide a user interface for testing.
Conclusion

OpenMoko’s ongoing development strategy is to evolve the ASU and FSO in parallel, and eventually replace the Qtopia phone bits with the FSO phone bits when FSO is sufficiently mature. The Illume launcher and other EFL-based software will be more tightly integrated with the phone functionality at that point and the Qtopia parts of the ASU will be scaled back incrementally. Eventually, the PIM functionality and other higher-level components will be retooled to work on FreeSmartphone.org specifications too.

The FreeRunner will come with om2007.2, but users can flash it with a recent build of ASU if they want to try the new stack. New image snapshots are released on a very regular basis, and users can find out what functionality is supported in each image by checking out the associated snapshot review page at the OpenMoko wiki.

Aside from platform integration considerations, there are a number of other issues that will factor into which toolkits third-party developers will decide to use for their OpenMoko applications. Qt will likely be a popular choice since it offers the highest level of portability. In addition to supporting all of the major desktop platforms, Qt also works on a broad selection of mobile platforms.

Nokia, which recently acquired Trolltech, will be making Qt libraries available for third-party applications in future versions of the Internet Tablet’s Maemo platform. It’s also worth noting that Qt 4.4 adds full support for Windows Mobile. We can also likely expect to see Nokia bring Qt support to its new open source Symbian platform at some point within the next year or two.

The Enlightenment libraries also provide a very compelling solution for rapid development of rich touchscreen applications for OpenMoko. We have already seen some wonderfully impressive programs made for Maemo with the E17 Edje and Evas frameworks. The Enlightenment libraries are very lightweight, which makes them especially good for mobile development.

GTK+ is obviously going to be the best choice for om2007.2 applications because it will enable third-party software to visually integrate with the platform. It will also enable developers to port some popular GTK-based Linux desktop applications like Pidgin and XChat.

There are a lot of very significant differences between OpenMoko’s software stacks and Google’s upcoming Android platform. Android takes a more top-down approach and completely eschews native code. Android offers one standardized Java-based API and One True Way to integrate with its platform. Google’s approach vastly simplifies development and neatly avoids fragmentation and portability problems, but it also imposes extreme constraints on flexibility, isolates Android-based phones from the existing Linux software ecosystem, and obscures a lot of the inherent strengths of a Linux-based platform. By comparison, OpenMoko’s software enthusiastically embraces the power and diversity of Linux but does so at a high cost in performance, consistency, reliability, and ease of development.

The OpenMoko platform strategy is clearly still evolving, but it has a lot to offer for developers who want a truly hackable Linux-based mobile phone that elevates freedom and choice. The biggest problem is that none of the three stacks are really fully functional in every respect at this stage of development. There are still gaps in completeness and reliability that will deter end users who want a smartphone that just works.

The difficulty of navigating the platform and toolkit choices could also frustrate some neophyte developers who just want to build software for the device. The tangled pile of mostly outdated and incomplete documentation at the OpenMoko wiki exacerbates the problem. I found a lot of very helpful and friendly people in the OpenMoko IRC channel on Freenode, however, so there is plenty of community support available for enthusiasts who need a helping hand to get started.

An important thing to remember is that the FreeRunner can always be flashed with new versions of the software. Users who are on the fence about whether or not to buy now should keep in mind that the device will become progressively more functional and usable as the ASU stack continues to evolve (you can check the progress at the OpenMoko wiki). Users who absolutely need reliability in a programmable smartphone right now are better off looking for more mature options, but enthusiasts who appreciate the potential of a truly hackable smartphone and are willing to be patient with some of the current inadequacies will probably find the current platform acceptable.
Further reading

* For additional details and pictures of the hardware, check out the Getting started guide at the OpenMoko wiki.

Source