Shiny geek toy?

hank williams hank777 at
Thu Dec 7 14:08:53 CET 2006

I think you are generally right, with some caveat.

It's really a chicken/egg problem. Will the carriers come first, or
the applications?

It is possible that in 2007, linux based extensible phones will become
the rage. We have greenphone, Access, and open moko. But if carriers
feel that these platforms threaten their lock on the platform, they
may not adopt. In that case it will require cheap phones and 3rd party
software communities to make a killer app that drives carriers to
adopt. If this is the case then this first version is really more a
shiny geek toy that ultimately motivates some great applicaton(s) that
then drive carrier adoption.


On 12/6/06, Christopher Heiny <heiny at> wrote:
> What exactly is it that we want OpenMoko to be?
> Do we really want a shiny geek toy?  Something that is super cool and
> technologically advanced, but only nerds will want to hack on?
> Or should we be working toward a solid OpenSource platform that will
> encourage other phone manufacturers to build on it and in turn give their
> work back to the community?
> To take a recently discussed example: an FPGA is really super cool and
> flexible and you can do just about anything with one.  But the downside is
> that it is HARD to do that stuff.  Even if you, personally, find VHDL or
> Verilog to be easy to work with and understand, the average engineer
> working at someplace like Samsung or Nokia (or wherever) will not have the
> same skills you do.
> Additionally, it takes time (lots of time) even for skilled engineers to
> design, implement, and debug new features for FPGAs.  Time to market is
> critical for most phone manufacturers, especially in countries such as
> Korea where product lifetimes are often measured in months.
> Yeah, we can trowel on all kinds of creamy technological goodness.  Myself,
> I want a dozen A-to-D channels so that I can use the phone for data
> collection and analysis in my race car.  Honest - that would absolutely
> rule!  But it's not what the customer on the street wants, and it's not
> what the manufacturer trying to sell to that customer wants.
> To be a success, in the same way that OpenSource projects like OpenOffice,
> Apache, Firefox, and others are successes, OpenMoko will have to provide a
> compelling reason for phone manufacturers to choose it over closed source
> options such as WinCE, Rexx, and others.  Five of the critical enablers to
> this are:
>     - rock solid reliablity.  Anything in the phone should "just work", and
> it must do it every time.
>     - complete functionality.  There should never, ever, be a greyed out
> button in the GUI.  Sure OpenMoko might support four different kinds of
> software radio, but if the manufacturer has to do their own I18N to pick up
> OpenMoko, they'll choose WinCE instead.
>     - desirable functionality.  Does the functionality provided by OpenMoko
> appeal to the typical human-on-the-street purchaser of this class of phone?
> Phone manufacturers are going to choose platforms that will help them sell
> the most phones, even for halo products.
>     - easy to customize or extend.  Not just by VHDL aces and Perl wizards,
> but by the average C/C++/Java programmer two years out of university.  His
> boss is going to choose a platform that plays to his skills (or lack
> thereof).
>     - support fast development.  That young coder in the previous bullet is
> going to be under a LOT of time pressure.  His boss is going to choose the
> platform that he feels will best help him meet schedule, and will see C++
> and Java as enablers, VHDL and Perl as barriers.
> Shiny geek toys are cool, and I love them.  But if we want to rule the
> world, they don't help that happen.  Once we've achieved world domination,
> we can add all the sparkly bits to OpenMoko we want.  Heck, people will
> probably be doing it for us.
>                                                 Chris
> _______________________________________________
> OpenMoko community mailing list
> community at

More information about the community mailing list