Openmoko on Design

[Jay Vaughan]

> A keyboard that always automatically knows when it is needed
> sounds great in theory, but prior to that perfect keyboard being
> implemented, what happened here was that users experienced a  
> degradation
> in usability and had no obvious means of restoring the lost
> functionality.  They were understandably frustrated by this.
>


It should be noted, also, that this degradation in usability occurred  
not just with the keyboard panel functionality, but with quite a few  
other things in the OM eco-sphere as well - bluetooth, for example,  
regressed, somewhere in between 2007.8 and 2008.2, as did audio, as  
has SDL support, and I think we could really come up with a list of  
quite a few things that 'sort of almost worked, and then stopped  
completely being usable' ..  It is a sensitivity to this back-stepping  
that leads me to a more vocal opinion about how the base distro  
platform is being managed at this time.

> At the same time we heard comments from a key developer who indicated
> that the decision was made above him by unnamed individuals with whom
> the community has no obvious means of communication, and who  
> apparently
> don't even listen to the reasonable technical arguments of key
> developers.  This also seemed to reveal something about the  
> internals of
> Openmoko that weren't expected: development decisions are not entirely
> made by the developers, but instead they answer to some people who the
> community cannot readily identify and who the community doesn't know  
> how
> to interact with or if they even can interact with these decision- 
> makers.
>

Thus putting lie to the 'its open, so fix it yourself' argument'.


> This led to another set of questions.  Many in the community presumed
> that they would be permitted to contribute code/ideas/design to the
> software stack that Openmoko is developing, i.e., ASU, but if there  
> are
> unnamed designers implementing a private design superstructure that
> overrides even Openmoko developers, then the usefulness or  
> likelihood of
> thinking that an ordinary end user could become an important part of
> that development process seems extremely diminished, if not
> extinguished.  This understandably disappointed developers who had  
> hoped
> to make such core contributions.

I concur with your excellent conclusion and only wish I could've been  
more eloquent on this issue personally.

>
> Sean's email only partially succeeds at this.
>

Actually, it raised alarm bells, in these quarters.  It appeared, to  
me, to be somewhat of a smoke-cloud in an attempt to provide cover  
over a situation that is detrimental to the survival of OpenMoko as a  
whole; not just as a company, but also as a community.  It is a CEO's  
job to provide smoke and mirrors when all else fails.

> "We're building an empty vessel for you to fill with your ideas." and
> "Change anything you want to our interface and we will gladly  
> deliver it
> to everyone." and these suggest that community contributions are
> welcome, even to the interface, and those contributions will  
> sometimes,
> at least, become an officially distributed part of the Openmoko
> interface.  So that tends to counteract those fears.
>

I think this is really more of a feint on the part of an embattled  
CEO, actually.  The two conditions: "we reserve certain parts of our  
system for our own designs", and "you can contribute whatever you want  
and we will distribute it to all and sundry" are not compatible.  Does  
not compute.

> Maybe some people were expecting from day one to use it as their
> everyday phone for push email, calendar, and contacts, and web  
> browsing
> and video/mp3 playback, and GPS applications-galore, all with a
> bluetooth headset that would be operated by accelerometers or  
> something.

This is as good a spec as we're going to get, isn't it?

 >Further, a number of developers have repeatedly asked with respect to
> option (1): How do I design my application to work with so many
> different stacks?  What should I be targeting?  Sometimes this gets
> answered with: "Take your pick!  The ultimate goal is for all such
> applications to work regardless, i.e., FSO is supposedly going to run
> GTK, Qt, or whatever-based apps."  But most developers who ask this
> question don't understand how that is supposed to work and need a  
> little
> more guidance on how to go about things so that they know that they
> aren't wasting their time building something that won't end up  
> working.
> That is, it sounds like these developers NEED some sort of design
> document so that they better understand where things are headed so  
> that
> they can do their part.

For my part I can help with this - I believe that developer tutorials  
that demonstrate how to operate in these environments and still  
produce a viable result are badly needed, so I am continuing the work  
I started with my DraftNotes last year, and will expand this to include:

1. How to set up a compile-onboard environment that works for new apps  
development, thus avoiding having to do battle with the ugly, ugly, OM  
elephant.
2. How to pick and choose your toolkits, and what are available.
3. How to target the different images that are out there already,  
effectively.


> truly open way.  However, if we're to have a benevolent dictatorship,
> then at least we need to know that's what we have.  When people know
> what to expect, they are less likely to get their feelings hurt.
>

I'm not bothered about hurt feelings, I'm bothered by the prospect  
that my applications won't have any users because the OpenMoko phone  
experience turns people away and so they just buy iPhones instead.   
Like it or not, we *{are}* in the same space as the iPhone, gadget- 
wise, whether we developers agree on the technical details or not:  
teenage girls and their grandmas don't know the difference.

> Again: it's been less than a month that the device has been on  
> sale.  I
> believe the Openmoko team has clearly been working overtime and  
> doing a
> great job at an overwhelming-sized task.  Everyone take a deep breath
> and let's find ways to work together.  (And, please: answers to some  
> key
> questions?)
>
> Brian
>

Well done, Brian, on formulating a positive, rational view of the scene.

;
--
Jay Vaughan