Community contributions to core apps & features. (Was: Terminal forASU)

onimas at onimas at
Sat Jul 26 13:44:21 CEST 2008


Please try to see the bigger picture. The questions you are posing have nothing to do with design, and everything to do with emotions. You see something you don't like, you want to understand why it was implemented, and how to change it. Its the same emotions that ignited Sean to start this project.  
It almost doesn't matter if we are an open project or not. Anyone with a fair amount of googling skills can hack phones. ASU's inititative, since day one, was to gather information from the internet and pipe it to the phone in an easy and accessable way. 
ASU is not in any way about design.   Its about organization. By removing a feature, we are forced to self-organize using the resources within our environment.  On the net, we would share ideas through the wiki, projects and mailing lists.  We hope to see this same type of sharing within the phone, using resources like installer (aka assassin). If you do not like a certain feature, please change it, document it and share it. I find these discussions ignited by Raster, highly contradicting, especially when he was the one defending the 'why should om support only one toolkit' discussions from a month ago.  Now, all of the sudden, we should support one distribution, that happens to include a qwerty button. ASU was designed to be empty, supporting various ideas, toolkits, skins, keyboards, you name it.  Getting into discussions about 'design decisions' is so entirely narrow that we are missing the point.  Everyone should fork. Everyone should create their own distribution, we only ask that this is done responsibily, by documenting it in a way where the benefits of your customizations can be shared by others.  
Our jobs as designers was to think about how to organize this  information within an ever evolving system, using the very resources available to us.   I can't say that we have succeeded in any way, we are still taking the first steps (actually we haven't even taken the first step, ASU isn't even officially released yet!).  I read every single mail on this list.  I believe in replying in a way that answers questions, not in a way that feeds to emotions, for the very reason that emotions can not be argued with.  I will also do my best to answer questions to be more transparent about our group, but please have some mercy!  We do work full time, and it is hard to keep up sometimes ;)



-----Original Message-----
From: Stroller <stroller at>

Date: Sat, 26 Jul 2008 08:46:55 
To: List for Openmoko community discussion<community at>
Cc: steve<steve at>
Subject: Community contributions to core apps & features. (Was: Terminal for

On 26 Jul 2008, at 03:10, steve wrote:

> Ask your questions stroller.
> I'll  do my best to answer them.

Hi Steve,

Thanks for your reply. I've posted my questions - or rather a request  
for openness & clarification - already in this thread. Because the  
background of the thread already contains all context you ought to  
need, it's difficult to know where to start asking you questions. Let  
me try.

On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote:
   the problem is the designers decided that ASU is not to have any
   manual keyboard toggle button because it will disturb the design
   and/or confuse users, so all apps and toolkits need modification
   to talk a "protocol" to bring up the keyboard on demand (no manual
   controls). that is why you need to do this.  personally i think you
   need a manual control because, as such, many apps and toolkits will
   not be changed, or they will get it wrong and give you a keyboard
   when you don't want one, or decide not to give you one when you
   do... but that's not my call.

- Who are the designers who decided that ASU is not to have any  
manual keyboard toggle button because it will "disturb the design and/ 
or confuse users" please? Was this a group of Openmoko employees? Or  
a single individual at Openmoko? Does this person have a specified  
role managing the design of ASU? Who do users bitch to if they don't  
like "design decisions"?
- How do you respond to Raster's suggestion that a "manual override"  
will be needed?
- Is a complicated "protocol" to bring up the keyboard on demand -  
which each input method will need to be patched to support - *really*  
better than a simple button?
- Will it be difficult to accommodate this protocol when porting an  
input method (Dasher, for instance) to Openmoko? Or will it be simple  
enough to do so that it easily justifies that lack of a manual  
keyboard button?

No. Ignore those questions.

This is only a small thing. I haven't followed the details of the  
problem closely - it was Raster's "i wanted to do this this way, but  
i wasn't allowed to" that surprised me - but it looks like the  
problems that this introduces aren't unmanageable.

What is of more concern is the connotations of this decision. As far  
as we (end-users on -community) are able to determine, a feature was  
removed by the process of someone @openmoko saying "I don't like  
that" and emailing Raster (or IRCing him or walking into his office)  
and saying "pull that" without saying to the users "hey, before we do  
this, are you using that feature? do *you* think it's ugly or  

Openmoko has always promoted itself as "fully open" - to quote  
Michael's words a couple of days ago:

   the goal of the project is not to create a new cellphone, but rather,
   that by being open, we allow and encourage innovation, and that by
   working with you, the open source community, we tap into a huge
   pool of imaginative, creative, very smart and hardworking innovators.

I have always understood Openmoko's openness to encompass the *entire  
breadth* of Openmoko software development. It's great if we can write  
apps for the Freerunner, but I can already write apps for Symbian or  
Windows Mobile. It's great that I can fork the code Openmoko are  
writing commercially and make modifications to the application  
manager or the dialler but that's obviously a duplication of effort -  
I thought you wanted the community to help contribute to the core  
applications, too. Isn't this the case?

Let's talk about the hypothetical community member Bob. Bob has a  
great idea a feature that he'd like to see on his mobile phone. Let's  
say he's meeting Charlie at cafe near the Linux convention and he  
thinks "it'd be great if I could select Charlie in my phone's  
addressbook and - alongside 'call contact' and 'SMS contact' - it  
said 'Send my location'. I'd just click that and it could SMS my GPS  
location to Charlie and on Charlie's phone it would pop up a message  
'Bob has sent you his location by SMS. Would you like to see where he  
is?' and then show a map with my location on it (or at least a needle  
showing distance and direction)".

Under a normal community development process Bob has some idea of  
whether or not other developers might like this idea. He can message  
them on IRC and say "would you include that in the main tree?" Bob  
can hack together a bit of code showing a working prototype and post  
patches to the mailing list knowing that the community will at least  
consider it. They might say "cool idea, but no-one'll use it, so we  
don't want it in the core distro", they might say "it needs a lot of  
polish", they might say "add a configuration option to enable/disable  
it". But even if they ultimately reject it, Bob can submit his code  
with some idea of the shared goals of the other developers and  
knowing that the idea will be considered on the merits of whether the  
other developers think it's cool or not.

I guess my assumption was that this was development process for  
Openmoko & ASU. There's a difference between goals of "the simplest  
mobile phone stack" and "the most configurable mobile phone stack"  
and "the coolest mobile phone stack", but basically I assumed that  
one could contribute to core apps and submissions would be considered  
by what the existing developers thought of the idea and the code.

It's a bit of work to implement Bob's idea. The contacts application  
has to be patched, as does the code which receives & displays SMS  
messages. You have to get the location from the GPS and you have to  
interface with existing map software or write your own program for  
showing location / destination.

The implication of the "designers decided that ASU is not to have any  
manual keyboard toggle button" is that one can undertake all the work  
for getting something like this prototyped and it'll be rejected out- 
of-hand by someone at Openmoko. And from Raster's reluctance to say  
who over-ruled him on the keyboard thing, one might not know who!  
There's no-one to appeal to! As I said before, even worse is the idea  
that the developers might think the idea is great and that it gets  
accepted and Bob does more work polishing and refining his idea, then  
it shows up in a daily build and someone at Openmoko notices enough  
to have it removed.

So the big question - assuming you DO want volunteer contributions to  
the core software stack - is "how do I know if my idea is worth  

There's apparently no design document saying where ASU (or whatever)  
is going in terms of features. We don't know who to contact in order  
to get approval for our concepts before we waste a lot of time on  
them. A developer probably doesn't want to go through some long pre- 
implementation approvals process before starting work - he doesn't  
want to create GUI mock-ups and write a long design-rationale  
proposal document (he just wants to dive into some code) but at least  
that way there'd be _some_ kind of process to go through.

I guess at some point this raises the goal of the Openmoko software  
stack. "Encouraging innovation" and "leveraging the synergies of our  
creative community" are just buzzwords when it comes to the final  
implementation details - I guess the whole point of Openmoko is to  
evolve into a software stack that you can install on your phones in  
order to sell more of your hardware, but should we be coding features  
suitable for little old ladies? Or should we be coding features aimed  
at typical Ubuntu users? Features to lure customers from Windows  
Mobile or Blackberry? As I said, I always assumed that features would  
be included if the community in general liked them, but right now I  
can't imagine anyone who can configure wifi and bluetooth being  
confused by a button to trigger an on-screen keyboard (such a button  
having been present in Windows Mobile 3 years ago), so I just can't  
make sense of this.

I started writing this message hoping to pose a handful of concise  
questions, but clearly I like the sound of my own typing too much for  
that. I'm sorry I'm so verbose, but I hope you can see the context of  
my concerns.


Openmoko community mailing list
community at

More information about the community mailing list