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]

Well, firstly, I'd say that getting power management to work on a mobile phone is an order or two of magnitude harder than a laptop. Not only do you have the usual suspects (applications, threads, backlights, screens blah blah) but you also have a radio circuit that needs to be on all the time, and needs to be able to quickly spin up and down if it's not being used in a wide variety of situations. It needs to regularly check the radio landscape, work out when to do handovers, check signal strengths and so forth, not to mention, you need to have a lot of logic in their to stop, for example, the radio stack doing massive high power frequency band sweeps when you go out of coverage. Tuning all of that, and getting it to work well with all the other stuff going on is a real development nightmare. Not to mention, each network, in each country is running different kit, doing different things so you need to run quite expensive test teams around the world tweaking things.

Other painful levels of abstraction... handling hardware acceleration for core codecs, for example, correctly handling the AMR11 (I think) codec for voice on a GSM phone. This will normally be a silicon codec on the radio ASIC, so you need to handle data pass through to the codec and handle how that interacts with the rest of the device, if you want to then do something like voice recording, other video with sound (H.264) you need to work out sensible ways of using the right acceleration at the right time.

Graphics... interfacing graphics to the screen drivers is a nightmare. Don't know why, but it seems to take thousands of man hours of hard graft to get working right and debug. If you then add another graphics abstraction layer on top of that it can be equally painful as you try and test and check to make sure things render correctly

Video/Audio multimedia... on dual core phones, you'll (as I've mentioned) have the audio codec running in hardware on the radio processor and video running in software or hardware on the application processor. Synchronisation of audio with video is a nightmare in those architectures. This is comon to a lot of the Marvel and TI family of processors for phones. Of course, a lot of this goes away if you stick a PC processor in and give it a Gig of memory, but that's not the direction most phone developers (with one exception) want to go in.

There's lots and lots more of those, but I'm not an engineer, I just have to tell people how much it's going to cost them for us to fix the problems when they encounter them.