About one week ago, I received my OpenMoko Freerunner. This is an openly developed mobile phone that runs purely on Free Software. So this is what I have to tell about it.
It was smaller than I thought, and is quite light. My girlfriend says it’s ugly, but I’m fine with the look of it. Besides being a GSM-phone, it comes with some nice gimmics: GPS, accelerometer, WLAN. The touchscreen works fine, although I don’t have anything to compare it with.
The system it comes with, even after upgrading, is still very rough. It mostly works for doing phone calls and SMSs, but there are a number of unsolved quirks that prevent me from using the Freerunner as my sole phone for now. The suspend mode is left too often, resulting in a battery life of about eight hours, and there are issues with the audio for the conversation partners, who will hear static and echoes. But, as this is free software, there is hope that this will be fixed eventually.
The OpenMoko distribution is based on Openembedded, which uses bitbake for building software. So if I got it right, and this is not sure, because documentation is rare and spread, there is the git repository at git.openmoko.org, which is a copy of the openembedded git repository. This contains bitbake recipies for all the packages, which includes where they can be downloaded, the package metadata (such as dependencies and version numbers) and sometimes patches. These recipies reference upstream tarballs or subversion URLs. For the “native” OpenMoko applications, the source is in the OpenMoko subversion repository.
One of the suggested ways of compiling software for the FreeRunner is by using a “toolchain” tarball, that can easily be extracted somewhere and used to build the software from the subversion repository, or other (hopefully autoconf’ed) software. This builds the binaries, but does not produce “proper” .ipk files, so no version number or dependencies.
The other way is the full openembedded setup, made easy using the MokoMakefile. This, automatically, fetches and builds everything needed for the cross compiliation and all available packages, producing the same output as can be found on the openmoko servers. Setting this up requires about 6 gigabytes of storage and takes over a day the first time, but then hacking the phone is relatively painless, as it resolves dependencies and is self-contained.
For a free software project, the state of the community is very important. The OpenMoko seems to suffer from a rush of interested people on the mailing lists, so it’s hard to follow real development in a mass of frequently asked questions and nice ideas from people who have neither an OpenMoko phone nor wil do any coding.
On the other hand, it’s not easy for new contributers. I have written some code that make sure the phone can handle numbers such as 0172/123 456 instead of the “official” +49172123456 in the phonebook and the SMS app, something that other users have complained about as well. But no one could tell me where and how I should submit my patches, and the mail to the mailing list with the patches and the bug report is unanswered. It is not clear, at least to me, who is responsible for what part of the project – quite different to what I’m used to from Debian, where there is a clear list of maintainers for each package, and a well known way of submitting patches (by going through bugs.debian.org).
For interested users, I have published my branch of the git repository at git.nomeata.de, and I will hopefully add more features and bugfixes later – at least when I find out how to properly contribute to OpenMoko.
Have something to say? You can post a comment by sending an e-Mail to me at <mail@joachim-breitner.de>, and I will include it here.
Photos
This "article" is a pissing joke