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]

Couple o things...

Spam SMS? Do you get these? Seriously, you shouldn't be - SMS is a network protocol and anything being sent is via their kit and they charge for it. So, in theory, you shouldn't get any spam. Filtering on rules is something more interesting and possible with MS and Symbian stuff.

The problem for anybody working in this is that Phones are a shiny consumer product and the addressable market for anything else is going to be pretty small. Making phones work is massively expensive in terms of man hours and I just can't see the model for this. I just can't.

[teaparty.net (from livejournal.com)]

yes, i get spam SMS. around contract-renewal time, i get a bunch of highly-undesirable get-your-service-through-us messages, which are definitely spam. moreover, i have automated systems sending me SMS, and i'd like to do client-side filtering on those so i'm not alerted except when i want to be. i could do some of that server-side, but (eg) the phone knows where i am, and the server doesn't, which makes client-side a better place to do "what time is it where i am today, and do i like being woken at that time" filtering.

i'm not convinced that "making phones work is massively expensive in terms of man hours and I just can't see the model for this.". making operating systems is massively expensive in terms of man-hours, but these can be and are made for free (see http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html , a 2002 estimate that red hat 7.1 involved around eight man-millenia of effort).

i'm not saying that all complex things can be made successfully on the free-software model. i'm saying that some can; mere complexity is no bar to a free-software model.

i have used open devices in the past that were failures (my agenda PDA, for one), because the code, in the end, didn't shape up. i have used open devices that were very successful (my laptop, under linux; my iRiver ogg player, under rockbox). i don't know which of these openmoko will turn out to be. i hope it will succeed, but i'm aware it may not. i'm not prepared to concede, however, that the project is implicitly impossible.

[daveon.livejournal.com]

I'm not saying it's impossible, I just don't see how the NRE costs (outside of the OS) can be handled by anybody sensible. Or rather, I don't see how that can be done and anybody can actually make any money out of it but producing a phone that enough people will want to buy to make it worth the effort. If people want to spend their time doing something for free that will not make them any return then I guess that's their call. I just don't know why, that's all.

As I've said in this thread, it's not just about software. A phone is a blending of Hardware and Software at a very low level. Getting all that to work together well and effectively is really really hard and takes a lot of time and the approval of third parties to agree that you can ship on their networks.

That costs a lot of time and effort and some very real upfront certification costs and typically the use of hardware that costs hundreds of thousands of dollars. This isn't something a group of individuals can generally do, unless they already have access to the equipment, or are prepared to be really generous.

[teaparty.net (from livejournal.com)]

certification's an interesting point. i have no doubt that you're right about it being normal to certify hardware in any given market, but i'm not yet convinced that it's mandatory. if the 'phone's not being sold in this country, by local dealers, yet the device is fully GSM-compliant, is there no middle ground for grey import and unsupported use? i wonder this aloud because i have to do the same thing, all the time, with my internet connections: my connecting firewall is a linux box, which is not certified or supported by any of my ISPs, and if they find me using it, some say they'll cut me off. but because the device is standards-compliant, they can't generally tell i'm using it.

you're also right about a phone being a "blending of Hardware and Software at a very low level", but so is (eg) a music player - and rockbox merrily works on those, without the hardware being designed to support it (in most cases, the hardware has to be reverse-engineered first). so this, too, is no bar in principle.

the idea, as with all open projects, is that the project becomes self-sustaining across multiple combinations: once there's working hardware and working code, the code may be ported to other (more popular) hardware, and other codes may be ported to the hardware. this has been known to happen, and it's also been known, often, to fail.

you may well be right about openmoko failing. hell, it may not even come to market in february. but if it does, the *very, very least* i can do is buy one, and try to use it. if i don't even do that, the project fails, and we're all stuck with closed 'phones that do only what the vendor and the networks will permit until the end of time, i can't complain.

[daveon.livejournal.com]

If you want something to attach to a GSM network then you need to pass the basic GCF certification tests and if it is a handset then it will need to have passed SAR testing too. No question. No grey area. It's really not quite the same thing as your home network. If your router or home TCPIP stack is a bit shit it's not that much of an issue except for you. If a mobile phone is a bit shit then it can actually tear down a GSM cell. WCDMA is a lot worse. They'll reasonably quickly spot IMEA numbers and block them at the HLR which will prevent them attaching to a network.

Believe me, they'll do it, as MS found out a few years ago.

I've no issue with the hardware getting reverse engineered, but, at least in mobile phones, the effort to do that runs into tens of thousands of hours effort just to get a BSP loading the OS at sensible quality. I have serious doubts that anybody who isn't being paid is going to be prepared to do it.

To put this in perspetive. The last port to new silicon we did for an open OS took nearly 40,000 man hours of effort.