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

[Carsten Haitzler (The Rasterman)]

On Sat, 26 Jul 2008 11:44:21 +0000 onimas at gmail.com babbled:

> Stroller,
> 
> 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

that is not the point. the point is that TEHCNICALLY many apps wont work
without a manual keyboard control - they need lots of modifying. the fact is
users DEMAND the control. automatic isn't reliable - and likely will never be
given a heterogeneous software environment. if you are apple and all
applications are your sand your write everything - you can guarantee everything
behaves one way. we are not apple. hell we don't have even a fraction o the
core systems or protocols or libraries etc. in place. we are in no position
currently - on s technical level, to pretend to do this.

> 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

never said - that. i said already i intend to fork off my own distribution.
for me ASU is not usable. the people here said "i don't want to fork - i want to
contribute to the core OS that openmoko supports and distributes". the way asu
is done requires forks. there is no contribution mechaism tat may in any
way affect design. multiple toolkits is a specious argument in this case. they
can all live together at the same time. on the same distribution and on the same
windowing system (well qtopia ported to x11 can. normal qtopia(on qws)
cannot... well.. that can be argued (implement a vfb in a window...)). the
existence and working of multiple toolkits is orthogonal to design and forking.

users were asking for something. a feature they need/want. they'd like it "out
of the box". they will not get it. it is not in the design. i cannot answer
for that. i can't change the design. they will need to do their own fork that is
a replacement package(set) to start enabling lots of features. it starts with
theme. like 2007.2 vs qtopia vs. FSO vs ASU pretty much, just a smaller scale.
there is a VAST difference of having multiple toolkits available together under
1 distribution and 1 ui core (x11), vs design decisions to remove features (the
keyboard button is a trivial one - as it can be brought back with a theme
change) but there are many other that once they are removed require massive
efforts to bring back (code changes, config changes that cannot be done as the
only way to do them is via guis' that have been disabled, so you need to do
temporary code hacks to force them back to lie and back to being accessible so
you can modify the config). for example - you now need to fork illume and make
your own illume packages. that also requires a cleanout of the user config if
they used it before. users dont WANT to do this. but that is what you (and
sean) want them to do.

multiple toolkits vs, forking packages... these are very different issues.

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

THIS is the problem. and i have been repremanded by sean for saying just this -
that you and sean said that everyone should fork, to me - do their own thing.
people asked if they need to do this, they fear needing to do it as it fragment
effort and they cant help the core system as they hoped to - and i said that
they need to. they need to do their own thing. i am just the messenger. i
"ignited" nothing - i simply said what was the facts in this case. i have
chosen my words carefully and have remained factual and neutral. i have
personal opinions on elements of design choice - based on technical
arguments, but that is as far as they can go in ASU. i am not able to make
design changes. it's not my call - i have been firmly informed of the
unhappiness of me doing anything in addition or differently to or other than
instructed to in the design. i thus cannot honor or consider any requests. what
do i do? simply not answer user emails requesting things? do i lie to them and
say "yes sure". and do nothing? do i sternly just say "no" with zero
explanation (and of course accept all the heat for saying no for a decision
that wasn't mine?)?

i made it clear *I* am not able to honor a request - the way for them to do it
is make their own fork - as you just said, but i am in a position where my
hands are tied.

> Everyone should create their own distribution, we only ask that this is done

and that is just what the community does not want to go doing. i know i don't.
the idea of using x is to minimise the need to fork - you have 1 display system
you can share. toolkits can live together. not all solutions to configuration
are "fork a package". it's configuration. options for a user to
enable/disable/swizzle with to make their device truly theirs. packages are not
the ultimate solution to all configuration.

> 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 ;)

please. please! respond. silence simply means more pressure on me when i simply
can't do anything. it is not my call, my decision, nor something i can do
anything about. that has been made clear to me. but those who make the decision
are not responding. silence. i have kept emotion out of any of my emails - just
raw facts and professional disagreement on a decision for technical reasons.
the community THINKS they are involved in the core OS and its design. the fact
is currently they are not. unless you actually interact with them and talk and
listen. design has emotive elements - on all sides. always. i have soled my
problem by just removing myself emotionally from it. i look at it impassively as
a job i have to do.

i've been calling on you (or sean) to speak up. if i make a design decision -
of any sort, i will always be able to speak up and explain it and/or defend it.
always. i may have been wrong - and if shown so - will admit it. but if i think
i am right - i will stand by it. at least users get an explanation of why they
get X and why they don't get to have X changed. :)

> Regards,
> 
> Will
> 
> -----Original Message-----
> From: Stroller <stroller at stellar.eclipse.co.uk>
> 
> Date: Sat, 26 Jul 2008 08:46:55 
> To: List for Openmoko community discussion<community at lists.openmoko.org>
> Cc: steve<steve at openmoko.com>
> Subject: Community contributions to core apps & features. (Was: Terminal for
> 	ASU)
> 
> 
> 
> 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.
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>