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 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 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 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.

Comments (14) left to “GTK, ASU, FSO? TMTLA!”

  1. Ron K Jeffries wrote:

    Thanks for clarifying what had been (to me) a rather confusing situation.

  2. Kevin Dean wrote:

    I suppose my only question at this point is “Where can I get current images” or “How can I build them”. FSO isn’t yet into MokoMakefile, should I bug rwhitby or is there a better/different way to build these images?

    Thanks for clarifying this!

  3. Jay Vaughan wrote:

    Bah! This is so infruriating. Why the fracture?

    As a developer, I had hoped Openmoko would get this right, but it seems you’ve just made all the justifications and none of the correct moves.

    There should be *one* stack, and one stack *only*, for all users to get used to, and developers to deliver to.

    This is confusing everyone, and muddies the scene around the OM initiative extensively.

    Where is the ‘official’ image, which all developers can target, reliably, and know that they’re not going to get boned by all the standard fracture?

  4. mickey wrote:

    @kevin: Rod has been so kind to add framework-image as a target. As we take the freedom to break things within milestones, there’s a chance it won’t work out-of-the-box though.

    @jay: Fracture is inevitable on an open system, where everyone can just start a new distribution at will. I agree though, it’s annoying for lots of people, but it’s not like we _planned_ to do that. It happened anyways, but with the new framework initative we hope to contain the damage and have a plan towards convergence.

  5. Jay Vaughan wrote:

    mickey: Fracture is inevitable, but there was no plan for it?

    For me, its quite simple. No phones carrying the OpenMoko brand ought to be being shipped, period, without the latest official build from OM being put on it.

    This means, yes, people can burn whatever image they want - that is the nature of things - but OM has one and only one image it puts on the phone, and it works to service the *hardware* being sold.

    All Open Source projects must bow to one, common, undefeatable reality: hardware comes first. Nothing gets shared, unless its on a machine and running in the first place.

    So, put the beef of your hardware manufacturing arrangements at the forefront of the effort to contain fracture. Make the machines that you ship, run the absolute latest build, and have your entire company running the same common weekly builds on products, too.

    It starts with the guys making hardware, and right now thats you. Us developers, the ones who want to target software to the platforms and are not making a dime of profit from hardware sales, can bring a lot to the table to make your hardware worth the pennies. But there has to be support, and you should use your strengths: nobody running OpenMoko today, or writing apps to target it as a platform, can do anything until the hardware is out there, running a common reference platform (software and hardware) that we all can depend on.

  6. Paul Boddie wrote:

    First of all, congratulations to the Openmoko team for getting this far!

    Now, I sympathise somewhat with Jay about all the confusion around the different software stacks, what people should be running, and so on. I’m an outsider who is considering getting a FreeRunner, but I’m concerned that I’ll need to spend huge amounts of time setting it up before I can even attempt to write any software for it. I imagine that some people are worried that they’ll end up having to buy another phone to “replace” the FreeRunner if there’s not enough movement towards having something that works and is usable within a certain timeframe.

    My attempts at getting started in advance of the release of the hardware didn’t really amount to very much because there seems to be a load of different pages on the Wiki recommending all sorts of different things…

    The MokoMakefile was convenient initially but apparently fragile and not that well documented, in my experience, but definitely a move in the right direction. The apparent fragility came about when trying to change certain files residing alongside the downloaded and built components, and quite some digging was necessary to find files in the filesystem layout that people were mentioning in other contexts. I also had to browse around to find out which qemu-related Makefile targets I needed and which other targets I should avoid.

    The “manual” approach (one of them, anyway - there are probably several) worked well enough until trying to get qemu to talk to the host, which apparently required the ridiculous exercise of entering commands in the terminal application of the emulated device using the on-screen keyboard. I’m sure I could “remaster” the images to just switch such stuff on automatically if I had the tools, but this didn’t seem to be particularly easy.

    (There are also flavours of host-based development which require the installation of huge numbers of packages. I can understand this, but I was starting to doubt the use of it as different preferred graphical toolkits started to shine in the continually moving spotlight.)

    I don’t care about there being many software stacks - I’d probably want to go my own way to an extent, anyway - but there has to be a lot more coherent information about getting started. It doesn’t help that a lot of pages seem to be out-of-date or incomplete - things may be moving quickly, but if that prevents people from getting involved, priorities should arguably change so that what should be a routine part of people’s existing workflow can be written up for others to follow.

    Anyway, I look forward to whatever comes out of the FSO developments, and hope that a straightforward path to getting involved emerges for those of us who like to concentrate on “user space” matters.

  7. Alexey Feldgendler wrote:

    While I understand how three different stacks ended up existing, what I’d really like to know is which one is going to be pre-installed on Freerunner handsets that eventually are sold to end users. If I’m going to make an application for Freerunner, I need to know what kind of operating system it will have when end-users get their hands on it. Sure, you can change from one image to another, but how many end users buying a mobile phone and expecting it to be just that are going to do that?

  8. Hudarsono wrote:

    “Us developers, the ones who want to target software to the platforms and are not making a dime of profit from hardware sales, can bring a lot to the table to make your hardware worth the pennies”

    From what I know so far, Likely openmoko really put a huge concern on building software stack rather than reliable hardware.
    And every developer can free express their creativity without any limitaion or what we can call strict framework like many other vendor. I think in the spirit of open source, this is good. Fracture is open source nature, since everybody often has different point of view and different way of though.
    As developer, it will be good if we can create our unique and differentiating value in this condition rather than just following “platform from vendor” as we did in closed phone.
    But as a buyer, what we buy from openmoko is mostly a hardware. I think buyer whose mostly developer will be more satified if they have good and reliable hardware to develop software with. We can change software if it’s not reliable, but hardware?
    So, hopefully openmoko team will put more effort to make strong and reliable hardware.

  9. Jorge E. Gomez wrote:

    So, let me get this straight: Every FreeRunner shipped with software that has already been abandoned?

  10. rune_kg wrote:

    Just bought a freerunner, here are my experiences with it so far.

    @Jorge E. Gomez
    That is correct. The “2007.2 GTK Image” which ships with the freerunner is not being developed on, and is in its current state very buggy and almost unusable.

    About the other available stacks:

    ASU: No recommended release yet, but shows promise. It is still unusable as a phone. Some things are very buggy/slow/chrashes.

    FSO: On alpha state. The only thing working is the dial-a-number function.

    Qtopia: Actually mostly works! When I feel like using my Freerunner as a phone this is the stack im using. Feels fast and responsive. No one in the community is developing for it, so very few extras are available.

  11. Woody wrote:

    Wow… Ok, so I’m a little tweaked.

    I tried the latest image and got ASU, which confused me quiet a bit. I also tried Qtopia, and then went back to 2007.2 and updated. It wasn’t the fastest, but it seemed stable and was pretty well documented, where the others either were super buggy or lacked openness or documentation.

    One thing I look for in opensource is documentation. 2007.2 is well documented, and clearly 80% of the openmoko site is geared toward it.

    I found this site accidentally via the list serve, and have to say I’m not happy with the documentation on ASU (and didn’t even know FSO existed until now…) FIC just shipped hundreds of new Freerunners with 2007.2 on it. I got news for you: Unless others hear about ASU and FSO, they’re going to be confused and hop back to the 2007.2 platform and start developing there. If you want people to be using ASU/FSO, you have to get that out there where someone’s going to see it and document what you’re doing. Nobody is going to switch to a new platform that’s not documented.

  12. mickey wrote:


    as for FSO: The new framework initiative overview wiki page is actually one of the first links from the mainpage, they even include my framework picture on the main page. From the overview page in the wiki there are links to the documentation and issue tracker sites. So, I don’t think it’s not documented.

    as for ASU: I’m not involved with that. It will eventually appear factory-installed.

  13. victor wrote:


    Thank you for this post. It seems to be helpful.

    Do you know how to download/install FSO milestone IV now? Download link disapeared some days ago from

  14. מאמר מצויין של Michael Lauer » חופש הדיבור wrote:

    [...] מצויין של Michael Lauer על הסטאטוס של הפיתוח של OpenMoko [...]

Post a Comment

*Required (Never published)