Juni 2008


With the new Openmoko Framework initiative (as posted in previous installments of this column) facing its first milestone release (nothing but solid phone calls, so don’t be disappointed. If you have no Openmoko device, check out the video in the same directory), we are now facing three different major software stacks for the Neo family (there are special-purpose variants, but I won’t go into details here).
As there is quite a chance that developers might be confused about that, I want to use this chance to sketch the big picture and answer some of the questions around the future of these stacks.


Openmoko is selling hardware products. Openmoko funds work on software stacks, so that the actual hardware can be more than just a developer board, but rather approaching a useful mobile compagnion. As with all kinds of products, Openmoko products have a — more or less specific — target audience. However, as we learned during all these months since we sketched the first product in the nice summer of 2006, even this specific target audience is not completely homogenous. The existance of the three software stacks is both due to the fact that we all are still learning how to write software for mobile devices, but also because there are quite substantial differences in what people expect from and want to do with their Openmoko devices.


So — what are these three stacks, where are the actual differences and who should run which stack? In a nutshell, it boils down to the following:

  1. The Openmoko 2007.2 Stack, utilizing GTK+ and assorted applications. 2007.2, since it was the 2nd iteration of the GTK+ user interface that we released in 2007.
  2. The ASU Stack, the combination of a classical smartphone stack based on Trolltech’s Qtopia ported to X11 and enhanced with an EFL-based launcher and new applications. You may have seen the term Illume which is the launcher of ASU.
  3. The FSO Stack, also known as the Openmoko Framework initiative. This one is called FSO, because it’s an implementation of the freesmartphone.org APIs. You may also have seen the term Zhone which describes the framework testing user interface and is a minor part of this stack.

Openmoko 2007.2 is for people who are familiar with the GNOME Mobile initiative and who want to write applications that run on multiple devices running (parts of) GNOME Mobile. This includes Maemo, which runs on the Nokia Internet Tablets. The strength of the GTK+ stack is a UI and programming environment similar to what you run on your Linux desktop, if you’re into GNOME. The GTK+ has PIM applications based on the Evolution Data Server and runs the gsmd phone server. Although you can use them, the applications are still pretty rough und unfinished. Some people have problems with the stability of the phone server.

ASU has been started to integrate the Qtopia stack — ported to X11 — with a new set of graphically pleasing applications based on the Enlightenment Foundation Libraries. Qtopia is a more mature product than the GNOME Mobile stack and you can expect all the standard feature phone applications to work in a solid way. It uses the Qtopia phone server. Since — contrary to standard Qtopia — it does not directly use the framebuffer, non-Qt applications can safely share the screen with Qt applications, that is until you are writing applications that do not communicate with the framework. If you want to integrate, then you’re back to C++ and Qt.

FSO has been started to overcome the deficiencies both of the 2007.2 and the ASU stack, namely to come up with an extensible framework that gives developers the infrastructure they need to create solid and exciting software products based on the Openmoko platform. An infrastructure that supports competing UIs while we can collaborate on developing services, making the framework strong . Here, the focus is on stable highlevel services that you can access from whatever language or UI that supports dbus. People report that despite its infancy, e.g. the phone server part in FSO is already more solid than anywhere else.


Right now, Openmoko’s priority is getting the ASU to a point where it is stable and satisfies the every-day use with the FreeRunner product. In parallel, Openmoko recognizes the framework initiative as critical for further iterations of their software stacks. The goal is to be able to take one application from one stack and replace it with an application from another stack. Once all applications are framework-aware, this goal can be reached — which also implies userdata compatibility between software stacks, of course!

In practice, this means once the framework has reached a certain extent (see http://trac.freesmartphone.org for our tasks, issues, and milestones), we can expect it to be seen in all kinds of products, likely including further releases of the ASU. Until then, the FSO image is already your best bet if you want to write something that is tailored for your special usecase. If you want, you could also help us shaping our framework-testing-toy Zhone into something that fulfills the daily needs 🙂

Of course, Openmoko would also love to see Openmoko 2007.2 getting more love, but they don’t have the resources to do it. If you are interested in working on it, here’s a strategy I’d recommend:

  1. Remove neod, gsmd, and phonekit.
  2. Integrate the framework phone subsystem and make the dialer talk fso.org OTAPI (substituting gsmd and phonekit).
  3. Integrate the framework device subsystem and make the launcher use it (substituting neod).
  4. Debug and polish the PIM applications.
  5. (optional and only when it’s ready) Integrate the framework PIM subsystem and make the PIM applications talk framework.

I hope that answered most of your questions. If not, feel free to add more via commenting this article.

Read more →


Momentum is something really strange! It’s hardly predictable and you have to run to catch it before it goes away — but when it’s there, things are progressing like there’s no tomorrow 🙂

There’s a whole lot of momentum present in some of the projects I care about:


  1. OpenEmbedded will abandon monotone and move to git as its primary SCM. This will increase the wide-spread adoption of OE and attract new people. We will have more (shortlived) branches and merges will be easier. We will also revamp the commit policies a bit to introduce more stability to both the stable and the unstable branches.
  2. Setting up the non-profit organization (german registered association e.V.) is progressing and we will soon have our legal entity.
  3. Some couraged people are revamping our website into something that’s more accurate, structured, (and pretty). Good for both OE-novices and experts.


  1. OpenEZX developers started to push for mainline inclusion. This will greatly increase the visibility of our project.
  2. OpenEZX developers are working on a 2nd stage bootloader that overwrites the MOTO kernel, but leaves the rest of the flash file system untouched — by this we can boot both an OpenEZX kernel from SD as well as the original system (with its kernel on SD), which makes testing a relief.
  3. We found security holes in the MOTOMAGX kernel, which may enable us to put our own code on these systems.
  4. Motorola has released new devices, apparantly running EZX. More devices for the platform!
  5. Openmoko’s Framework and Zhone phone UI is going to provide a slick looking — working — featurephone userland for OpenEZX — the first releases are just a couple of days away. It’s now important we get kernel work finished, so we can release something that is a real alternative to the closed source MOTO system on EZX devices.


  1. Openmoko successfully went into mass production of the Neo FreeRunner (GTA02) device. Finally, people will have the 2nd generation of the first truly open source hardware platform in their hands.
  2. The Qtopia/Enlightenment based next generation software update is progressing nicely. I expect a release in the next couple of weeks.
  3. The new dbus-centric Openmoko framework initiative as well as the Zhone bread-and-butter application will see a release within the next 48 hours.

Exciting times for Linux on mobile platforms, n’est-ce pas?

Read more →

State Machines — Resistance is Futile

Open Phone Server State Machine

So I’m rewriting the call handling in the Open Phone Daemon for the second time now. Cowardly, twice I tried to get away without implementing a full state machine, but it always came back to me.

Telecommunication stuff is all about state machines, and honestly… they are your friend, not your enemy.

Yet another reason to see that my third semester in university with all the finite state machines was not superflous 😀

Read more →


I seem incapable of working together with some people. I tried hard, but it just doesn’t work. Everytime we discuss anything my blood pressure is raising and we run into arguments. I’m sick of that. Perhaps it’s just me — I’m afraid the older I get, the less patient I get. Then again, it could be just a matter of chemistry — some pairs function, some not. Might be nature.

Read more →