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

[pjc50.livejournal.com]

Your impression is radically different from mine; e.g. I know mjg59 who does very hard work in getting power management to work on laptops under linux. There certainly are a few Eric Raymonds around, and I'm unimpressed by the "Ruby on Rails" lot, but I'm curious as to what you think the "level of abstraction which has been made easy by people doing the hard stuff" is.

[celestialweasel.livejournal.com]

It is the 'Ruby on Rails' lot I am thinking of in particular, and if you were to look at the average open source blogger most are of that ilk. The fact that you know one person doing hard stuff doesn't mean that most people aren't.
If I had to given an example I would say 'the internet' in all its messy physical glory, there is a lot more to it than passing a few TCP / UDP packets around.

[blue-condition.livejournal.com]

Most of 'the internet' has been developed by professionals, with support from their employers.

Weenieware is something that some kid scrapes onto sourceforge and ignores the support requests for, but adds K3wl Th3M3Z0rZZZ!!!!" to.

[blue-condition.livejournal.com]

One Eric Raymond is an Eric Raymond too many. For all that he talks a good game about OSS, what has he ever actually contributed?

Man's a gunw*nk c*nt. I object to the way he runs|ran the Jargon File, even.

[celestialweasel.livejournal.com]

As you may know, the original Jargon file can be found (search for Original Jargon File - the main site, dourish.com, seems to be down at the moment) before it was mutated by ESR. It is, for those of us who are middle aged and bitter and twisted, amusing that in the original things refer to LISP / Lisp Machines rather than C and UNIX, particularly because in general the complaints made by the Lisp / Lisp machine people about C / UNIX are almost identical to the complaints made by C / UNIX people about VB / Windows people.

[blue-condition.livejournal.com]

I have what I think is the last GLS version of the File. Much funnier, less political axes to grind, and, when it comes down to it, considerably more erudite. Raymond's wrecked it with heavyhanded open-source advocacy.

[miramon.livejournal.com]

Wasn't he responsible for fetchmail? At least it has his name all over it.

[blue-condition.livejournal.com]

IIRC ESR inherited an earlier POP client, hacked the "deliver to local SMTP port" onto it and tarted up the user interface.

I've still never found a major piece of systems work ESR has done that's found a wide user base. Fetchmail is something you could hack up in a weekend, not a serious piece of software engineering. He talks a good system... if you happen to think the 'bazaar' approach is anything other than contemptible ;P

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