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.
A week and you told us fuck all basically other than its open. Go try the iPhone which has a real multitouch electricity based touch screen, Freerunner has a crappy ancient pressure based screen that needs a stylus most of the time.
Sorry, what are you trying to say? That I should submit my patches to apple, for inclusion in the next iphone? Wheres the source BTW? And while we are at it, I haven’t seen an offering of an iphone that works with O2.
I have the previous model, the neo1973. Despite the best efforts of the team at FIC (and they are highly appreciated) I think this model is still not prime time, still a developer phone (which is why I got it in the first place). But I'm counting on people like you to convince me otherwise - I might just but a FreeRunner yet :)
Thanks for sharing your experience. I'm one of those not who are still waiting for my device. I was hoping for python+gtk to be what I'd learn to be able to contribute. Now I'm not sure what is needed (and to which UI/framework to contribute).
Anyway, thanks for your efforts and keep it up - it will get better as things mature and summer vacations (and Summer of Code projects) are over.
Thanks for the update there...I actually didn't know the full state of the device other than what I've read on the site. I was really looking forward to getting one of these phones but I've decided to hold back for it to become a bit stable...and I know that this is what a lot of people are doing and it's not the best for the community as it requires early adopters...just like any other product
You can hold back having it in your pocket ;-) besides GPS hopefully there would be no other 'hardware' issues, thus waiting just helps you out to stay away from playing with FR. The main problem, in line with Joachim's comments, is lack of the organization among the community -- it is just a single architecture! but many people need to invest their time to redo smth what someone else have done, since it wasn't fed into the main repository... sad
I've been tinkering around with the FR for about a week as well, and have run into pretty much the same problems. I really like this project, but until somebody starts organizing all the developers, it doesn't seem like it'll go very far. I hope that happens sooner than later.
Thanks for the post! It's nice to know I'm not the only to be affected by these issues.