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

[Stroller]

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  
confusing?"

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  
pursuing?"

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.

Stroller.