OpenMoko: Taking Open Source slightly too far?

[major_clanger]

During my discussion of mobile phone options I was pointed at OpenMoko, a project to create an open-source phone. It looks intriguing, but I have to say that I have concerns.

Firstly, my experiences with open-source make me rather wary of what using such a device will be like. A mobile phone is a consumer gadget, and one that it's easy to become very reliant on. If it crashes or misbehaves, I don't want to be told that there's a user forum where enthusiastic geeks can help me diagnose the problem. I want the phone to work, to stay working, and to be returnable to a dealer for replacement if it stops working.

Secondly, what about security? Not so much of the phone itself - I acknowledge that open-source systems can in fact be more secure than proprietary ones - but of the network. If the phone is open and hackable, how long before hacks start appearing that fiddle around with elements of its configuration that network providers are usually very keen stay set to predetermined states? In the short term, users might get better call quality, but how long will a cell network stay up if this sort of abuse becomes common?

Finally, what I know about the mobile phone industry suggests to me that it is an extremely technically sophisticated area. I don't doubt the enthusiasm of the OpenMoko developers, but are they biting off more than they can chew? Looking at the project wiki, some four months after development phones became available the latest news is as follows:

The Openmoko snapshot from 20071113, when employing a few steps, can sometimes (depending on the moon) make and receive calls but the dialer is in early alpha-testing state! Also note that there NO graphical frontend for handling SMS is included. Power management (suspend) is still flaky.

This for a product that is allegedly going to user release early next year!

Say what you will about the iPhone; you can at least use it to make calls with.

Comments

[celestialweasel.livejournal.com]

sms -n 07123456789 -m "typing command lines in T9 is fun"

I think you know Mr daveon, I'm sure he will be along shortly to comment (allowing for time zone differences).

My impression is that a lot of open source people think things are easy because they are working at a level of abstraction which has been made easy by people doing the hard stuff (clearly some of the hard stuff is done by open source, but the majority of the open source blowhards in the noosphere aren't doing hard stuff - I am trying to promulgate the term 'froth jockeys' for them, on the basis that they are providing the thin layer of froth on top of the liquid (coffee / beer)).

call -n13346 -hangup

[pjc50.livejournal.com]

If you don't want one, don't get one? It's not like there's a shortage of phone designs.

Coincidentally I just read: http://www.f-secure.com/weblog/archives/00001322.html about hacking the iPhone. Basically all phones of a certain level of sophistication are general-purpose computers on which any software can be run, it's just that the openmoko phone is designed to be particularly convenient.

The network itself is fairly well protected as on nearly all phones (including the openmoko phone and the iphone) the GSM logic is on a seperate processor which communicates with the UI one over a serial link. This makes it a lot easier to get regulatory approval for the design, because it guarantees reliability of the GSM level.

Phone software reliability by big names is hardly guaranteed: My T610 crashed a few times, necessitating removing the battery and rebooting it.

People want all sorts of different things from phones. An open source phone is for people with particularly individual wants. Myself, I'd settle for a phone with a fast user interface that has no visible delay between pressing a button and moving around the menus.

[blue-condition.livejournal.com]

One of my favourite wikipedia entries is that for weenieware, started by a former colleague of mine.

I want software that's written by someone whose mortgage and livelihood depends on the quality, not something tossed off by some malodorous virgin student in a baseball cap, stonewashed jeans, an allegedly humorous Perl t-shirt and a crap moustache.

High-consequence software - only trust it if it's by someone to whom it has personally high consequences ;)

[aardvark179.livejournal.com]

As has been said the baseband software is generally separated out. Software controlled radios are good but the the low level software is part of the FCC licensing so it must not be part of a user hackable OS.

I don't worry about the stability of such an open source phone, they'll get that right (or as right as any other major phone manufacturer does) but I do worry about UI design.

I'm not sure why I'm worrying though, I mean UIQ/SE appear to have completely fucked up the later P series phones as regards UI goes, and there's plenty of other awful examples out there, so it's not like supposedly well organised closed source teams with UI designers can't screw that side of things up just as well.

I do worry that there's an X windows box on openmoko's architecture diagram though.

[daveon.livejournal.com]

Ok, my 4 pennies...

Point 1:
So far, based on the projects we've done, there isn't a Linux phone out there yet that matches an RTOS (Real Time Operating System), Symbian or WinMo phone for general quality of finish. One of the core problems here is you, as the user, really don't want to be reflashing your phone ROM too much - it's not something I'd do with something I'd paid for, but I'll let people do it with test hardware I'm leant.

Of the several dozen live phone projects we're working on at the moment, only 1 or 2 are Linux and most of those have ended up "dumped" on the market in China because none of the European networks would accept them quality wise. It's why I'm agnostic about Android, there's been several Linux/Java platforms produced and most of them have flopped because in order to keep them working they have to be locked down to a certain extent to avoid somebody buggering up some of the hard stuff.

Point 2: Split into many little points...
This is a tricky one. As another person mentions, the easiest way to get around this is to have a second processor running the radio stack and have a command line interface to the OS - historically this would be AT commands, although most people are moving to an open API. This is easy to build, and is the approach Apple took, however, you'll find it won't be as reliable as a purpose build phone platform like you'd get from Sony Ericsson or Nokia. It also pushes the price up. From what I've been told, this is also true of the iPhone as an actual phone, but most people don't mind because it's shiny.

Having 2 cores also pushes the prices up and makes power management a nightmare, so what you see are most of the silicon providers pushing for single core where the radio and application processor are on the same chipset. This is harder to integrate and get to work, but the results are worth it. Of course, testing and debugging a phone to the expected quality of a typical user is a huge undertaking and requires access to a lot of really really expensive kit, like Anite or Rhode and Swartz network emmulators and a real Faraday cage. I worry that the open source people won't have access to these million dollar goodies.

Finally, network security and networks are a problem which is why, to a greater or lesser extent all the open source options will either be locked down or come without the network logic which will have to be added as a black box later. Manipulating, for example, the Quality of Service system on a WCDMA network can tear down a local cell and I don't think that the phone companies nor the government will be happy with people being sold a hacking tool for networks.

Even then, quality can be a problem. I know of a trial in 2003 where 20,000 test phones pulled down a major network's Base Stations in the London area.

Android is more likely to be a better bet and work better because Google are at least subsidizing the phones, but I just don't see true Open Source surviving an encounter with the demands of consumer quality mass market products with significant 3rd party dependancies.

[teaparty.net (from livejournal.com)]

to address the immediate question: yes, this is still very much a work-in-progress. still, take heart from http://informationhunger.blogspot.com/2007/11/openmoko-is-growing.html - his comment of 2007-11-24 that "the dialer and sms handling is also being worked at in a furious pace by the OpenedHand guys. Since about a week, calling has worked without any problems for me." suggests that your fears of 2007-11-13 have been addressed.

note also that the recent discovery of a power-management hardware bug means that the final device has to be respun again; GTA02v5 is now looking to ship in early february. the aim of the game is to have good-quality code by ship-time; if things continue as they have, this is likely to happen.

and now, the wider question. the aim of the game isn't to deliver a slick consumer device. if you want one of those, oh consumer, then buy an iphone, a nokia, or your shiny-phone-of-choice, but for the love of Steve, *stop bloody complaining about how you can't run ${APP} on it, and how the vendor tries to punish you if you do*. the aim of this game is to offer a *choice* to users: if you want a sealed device, with a predictable user experience, then buy one, and live with the user experience you've plumped for; if you want an open device, which will require understanding and love and attention, but is at least as fixable as it is in need of fixing, then go openmoko.

why would i do this? personally, integration of spamassassin and SMS strikes me as a must-have; i am aware of no 'phone that offers anything remotely like this ("this" being a combined bayesian and rules-based inbound SMS filter). even just procmail for inbound SMS would make my life much better. i have no idea if anyone else on the planet wants this, but i do, and i can see how to do it on the openmoko. i expect that others who have strong feelings about what they want their devices to do, will have comparable, yet different, must-have lists. their lists will not impact on my 'phone, unless i really like something that (eg) simon likes on his 'phone, in which case i can put that on my device, too.

andy powell's must-have that he writes about at http://blog.automated.it/2007/11/21/here-i-am-right-here/ , code which can automatically contact his wife as soon as (but not until) he arrives at the Channel Tunnel, is a great example. i have no need for that, and i doubt most people will; but he does, and he can have it, without overloading my 'phone with bloaty code i don't use.

to briefly address daveon's fears about reflashing: i can't comment on openmoko _per se_, as i haven't got one yet, but rockbox (which i run on my ogg player) distinguishes between updates to the boot code (which is capable of allowing a new bootable image to be uploaded, and is itself updated very rarely) and updates to the bootable OS (which does most of what the device is supposed to do, and is updated continually). this tends to defuse most of the scenarios that end up bricking a device; if bleeding-edge doesn't work, upload last-known-good and continue with life until yet another bleeding-edge version is available to try. what i've read about openmoko's cramfs makes me think that they're taking this approach.

[teaparty.net (from livejournal.com)]

you're telling me that you seriously doubt that something that takes 40,000 man-hours can be done for free. i've already pointed out to you that something taking about *sixteen million* man-hours of time was merrily distributed for free (both zero-cost and unencumbered).

i know this may beggar belief, but it's true. i freely accept that doesn't mean that all tasks that take a million man-hours can be done with neither cost nor encumbrance to the end-user, but *some clearly can*.

i don't know whether openmoko is such a task, but that might make a more interesting discussion point than "i seriously doubt that such tasks exist", which isn't hugely convincing.

on the subject of QA, you've sunk a boat i wasn't floating. i happily accept that the networks will block _en banc_ devices which are shown to adversely affect network ops. my question is whether there's a strong correlation between devices which aren't tested on the expensive testbeds you describe and devices which adversely affect network ops.

i note also that the GSM hardware in the openmoko is pretty tightly tied-down on the network-facing side. even the wiki merely notes that "we cannot provide many details on the GSM chipset due to very tight NDAs", but they go on to add that "this is not neccessarily (sic) required, since it interfaces using a standard UART serial line with the S3C2410. On that interface, GSM 07.05, GSM 07.10 and other standardized protocols are used.". i'm no GSM protocol expert, and you sound like you might be, so it'd be interesting to hear your thoughts about that model of interaction with the GSM infrastructure.

WCDMA instabilities are sad but not relevant here, since openmoko don't propose to make a WCDMA 'phone.