I have not been posting about my work for Openmoko for quite a while. There are multiple reasons for that, ask me privately if you want to know… Today though, I want to post about a high-priority project inside Openmoko, Inc. — the new framework and middleware initiative which me and some guys will be working on.

I have been talking privatly about this to people on conferences, but now it’s going to be an official project. It’s something we attempted to do when we started back in 2006, but for some reason, we did it the wrong way. We tried taking existing components to make them fulfill our usecases and to fit our needs, which in some cases turned out to be impossible. This time we’re moving the other way round. We will take our usecases as the goal and create the necessary infrastructure to make it happen. If — while we’re on the way — can integrate existing efforts, even better. If not, we will eventually see how to merge with existing efforts. The goal is to get things done — now!.

Basically all this is about two components, which are independent, but closely related.

1. The framework.
2. A bread-and-butter application.

The Framework

The purpose here is:

• Give people the infrastructure to create solid and exciting software products based on the Openmoko platform,
• Support competing UIs while collaborating on developing services, and
• Encourage framework users (e.g. application developers) to also contribute to the framework.

With this in mind, we define the following requirements:

• Make it simple,
• Concentrate on core services,
• Be programming language agnostic,
• Be UI toolkit agnostic, and
• Try to reuse existing technologies as much as possible, but not at the cost of a bad API.

Our way to achieve this on a technical level is through dbus:

• Chose dbus as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.
• Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).
• Optimize for Openmoko devices, but support multiple architectures (OpenEZX, Xanadu, …) and purposes through plugin interfaces and suitable hardware abstraction mechanisms.
• Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.

The framework is not going to cover everything but the kitchen sink though, especially it’s not about:

• Bootloader, Kernel, or System Init.
• X-Window-System, Window Manager, UI Toolkits,
• Application Launchers, Applications, or Fancy UIs.

The Bread-and-Butter application

The framework initiative is related to developing an application that uses the framework to turn a Linux-phone into a usable feature phone. The main goals for this application are:

• Make it simple,
• Concentrate on core features,
• Have a beautiful, efficient and consistent UI,
• Be easily extensible through scripting, and
• Show the power of the framework.

This application is developed in tandem with the framework, because when you write framework APIs, it’s important to have existing API consumers. Without API consumers, APIs are just specs, could be awkyard, or plainly unusable — that’s why this bread-and-butter application is of central importance to the framework project.

I’m looking forward to spend a lot of time on this project and I invite all of you to participate. Most of the discussions will happen on the Openmoko developers mailing list and the FreeSmartPhone standards list We already have achieved some important basics thanks to great contributions by the moko underground people that are grouped around the neo1973-germany.de site and the IRC channel #neo1973-germany. I’m also looking forward to great results from this years’ Openmoko Google Summer of Code.
As for the current status, we will update the wiki page OpenmokoFramework frequently and sent status updates once and then to the mailing lists.

Good speed!