Openmoko on Design

[Brian C]

Sean Moss-Pultz wrote:
> 
> Dear Community
> 
> 
> Design.

This is a long, careful response to Sean's "Openmoko on Design" post.

If one goes back to the beginning of the "Terminal for ASU" thread, what
you find is that several users were just getting things set up and
mostly working in ASU and then they upgraded and found numerous things
were broken because they no longer had a means of manually bringing up a
keyboard.  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.

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.

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.

When prodded to respond, Openmoko employees indicated a willingness to
answer questions.  At least the following very specific questions were
asked:

1) Who is Openmoko's "design department"?
2) Many in the community believed that Openmoko wanted the community to
contribute code to the core applications/functionality of the software
stack.  Is this not the case?
3) If the design department is operating from a design document, has it
been made public?  If so, where?  If not, why not?

Sean responded with a lengthy email.  It illustrated again why he is the
CEO.  A CEO needs to be focused on the big picture, as was his response.
 A CEO also needs to point his or her team and the customers towards
that vision.  Sean's email was great at this.  However, I think many in
the community just wanted some specific answers to the questions above.
 Sean's email only partially succeeds at this.

We learned:

"Being open doesn't mean we put the essential ideas behind each product
to a public vote." which suggests that there may be some parts of what
Openmoko is developing that the community will not have a means of
directly participating in, and tends to confirm some of the fears
expressed above.

But we also learned:

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

And while we didn't get any answer to question (1)--who is the design
team?--we were told that an answer to question (3)--is there a design
doc?--would require working as an Openmoko employee for several months.
 I think the implication of this has to be that, No, there isn't a
single design document that can be pointed to at this moment that
explains every decision made or priority had by the Openmoko team.  OK.
 Fine.

Everyone should step back and recognize that the device has not even
been on sale for a full month.

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.
 But we all recognize now that it's not there yet.

So, we all should also recognize that there are a million little (and
some big) things that need to be done to get the device to have all the
capabilities that its hardware make possible.

But the community can have (at least) two distinct ways of helping with
that giant TODO list.  1) The community can build applications that run
on a framework delivered to us by the Openmoko team; or 2) the community
can be directly involved in working on the underlying framework on the
device; or 3) both.

It was this incident with the keyboard that made several people believe
option (2) was not available, and even after Sean's message, I still
don't believe that we know the answer.  So, I'll ask again: does
Openmoko intend to allow direct code contributions by community members
to core components of the ASU/FSO frameworks?  If so, will such
community members also have a voice in underlying design decisions that
guide that/those framework(s)?

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.

Personally, I think the TODO list is SO large right now, and the
underlying framework so in need of development, that Openmoko would be
making a huge mistake to lock the community out of that core development
process.  If there are people willing to shut up and code, they should
be welcomed with open arms into each and every piece of code that runs
on the Freerunner so that we all get a functional platform faster.  But
if it makes sense to trust the community with that sort of contribution,
then it cannot make sense for an actual paid Openmoko developer to also
be in the position of saying, "we are paid by openmoko to do what  we
are told to do by the design department and that is what we then do."
If that's the state of things for paid developers, then community
contributors have even less hope. Openmoko has to trust those members of
the community, who prove themselves through actual contributions, to be
worthy to give input on larger design issues as well.  That would be the
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.

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