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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community