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

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

[dgh.livejournal.com]

I suspect that most companies that deploy a free software based stack will lock down basic functionality. Having a phone based on free software doesn't necessarily mean that you can modify the software on it. (GPLv3 takes a stance against this, which means that anything you want to lock down can't use GPLv3 software.)

Motorola have been using Linux on their phones for a while:

http://www.news.com/2100-1001-984424.html

However, this has not translated into any additional freedom for Motorola customers.

[daveon.livejournal.com]

It's used as the OS on a fair number of Chinese "feature" phones. They're locked down and won't run applications and they're cheap. However, China is something of a dumping ground for handsets that operators elsewhere won't touch. Mitac were able to ship hundreds of thousands of their Windows Mobile devices there even though they'd been refused by every European and US operator.