A marketing angle

[Richard Franks]

On Wed, 2006-11-22 at 23:36 +0000, Ben F-W wrote:
> Richard Franks wrote:
> > <snip> the main competitive
> > differentiation is that you will be able to find software for the phone
> > to do just about anything. That is, instead of focusing on a particular
> > 'killer app', make the 'killer app' the fact that you are not being
> > restricted by or charged for features or applications.
>   
> I can certainly see that being interesting for a subset of people, 
> Richard: those who *want* to be pushing the boundaries of what their 
> phone can do. But the majority of people want, as Graham Perrin put it, 
> "the clicky speaky thing in my hand/pocket... to be as *simple* as 
> possible". The ability to add new programs means unlimited opportunity 
> to some, unlimited complexity to others, and I think people will need a 
> clear, proven, safe, simple benefit to draw them over to the OpenMoko.
> 
> I'd be happy to be proved wrong - but certainly for desktop Linux, the 
> benefit you mention doesn't seem to be enough of a draw for the majority.

I agree absolutely with the thrust of your statement - traditionally
more software = more complexity = less reliability. There is correlation
definitely, but I'd debate whether we're observing causation.

We want to (in general, I think these are safe assumptions):
* Maximise software choices
* Minimise complexity
* Maximise reliability

Traditionally software applications for the major platforms are
developed using radically different technologies, by many different
entities, all of which are enabled by the underlying OS in a rather
ad-hoc 'patchwork' manner. c.f. usb support through Win95->Win2k.

By creating a new framework from scratch, you have the opportunity to
circumvent a lot of these problems. For example, if your application
exclusively uses the OpenMoko API, and makes no OS calls.. then assuming
backwards compatibility isn't broken by subsequent OpenMoko releases..
your application is going to play nice forever. Furthermore, it's going
to be easier to port to other OpenMoko hardware platforms.

Of course, this would mean that the application/framework communication
architecture has to be fully fleshed out from the start - just one
simple example of event handling would be whether your app exits from a
system callback, or has to handle (correctly) its own input and
shutdown?

It comes down to design -- the most elegant designs marry underlying
complexity with simple (non-scary) end-user interfaces. If OpenMoko
delivers on that front then the possibility exists to break the
unlimited options=complexity mindset.

That said, all that does is create the foundation for the 'killer app'
itself. Maybe a more scalable approach would be instead of focusing on
one grand amazing killer-application, create a little family of
less-ambitious but more easily achievable micro-apps which each perform
a simple function well?

Cheers,
Richard