Lessons Learned

From Qi-Hardware
Jump to: navigation, search

Over the course of our time at Openmoko Wolfgang Spraul and I learned many lessons. Wolfgang spent some time with Werner Almesberger collecting his thoughts, and I’ve put together this compilation of our collective “wisdom.” We all take different lessons from our shared experience and we all hope that we don’t commit the same mistakes over again. To paraphrase Werner, one reason to review the mistakes of the past is this: In the future we want to make new mistakes.

1. We need more partners: more existing products to open up, more sourcing options, manufacturing options including assembly and production testing, and semiconductors. In the past we had great partners so we intend to build on that and expand it. In the past I’ve used two approaches to designing new products. Starting with a design goal and sourcing components to meet that goal and starting with a cool technology, say a chip, and designing products around that chip. In our approach that means we would start with open components and open partners and drive their roadmaps forward. Start, for example, with an open electronic dictionary and drive that design by adding other technology. Or start with an open wifi solution and drive products around that center. Let’s call this grass roots design. Start with a solid root, open root, and nurture that plant.

2. Hardware design does not tolerate feature changes mid-term, devices need to be finished and marketed as specified when the hardware design project was kicked off. The community doesn’t tolerate “marketing” spin. We see right through it, and we have no patience for over promising and under delivering. Throughout the course of our collective careers we have seen many projects wander their way to oblivion because of mid course second guessing and mid course corrections. Qi demands we do things differently.

3. Publish a credible roadmap. We will always strive to have our our products rooted in shipping hardware backed by a solid roadmap for the future. At every stage future products will look better than current products and every marketing bone in our body screams “Osborne’s effect.” Does “leaking” our future imperil our current products? In reality ”Osborne’s effect” helps us define our target customer even more clearly. Our customer is exactly that person who is committed to the dream of the roadmap. They realize that tommorrow’s product replaces today’s product. But that fact doesnt stop them from buying the current product. There are two factors at play here. One, they are developers; they know hardware gets better. The more they know about the roadmap the more secure they are in investing their software talent in today’s platform. Two, they are free software source developers, and they know that open hardware can’t really be End-of-Lifed.

4. The kernel and drivers need to be developed by a semiconductor provider as a first step. Moving this upstream is a key goal for us. We need to accept the semiconductor kernel and driver as a start, no matter how ugly it is. If drivers from several vendors are based on different base kernels, we will stitch them together, and should not try to clean it all up. Don’t make the userland developers wait for the perfect kernel. But we can’t stop there. We must drive kernels upstream. The value added by the community that happens in the user space requires stable hardware and stable low level software and as we add software talent we need to focus that talent on moving kernels upstream.

5. A company is built around sales, marketing and customer service - not around engineers. Marketing did not write this, honest.

6. Focus your open efforts: free the hardware FIRST, not your ERP system, shopping cart,blog software, and factory.

7. User interface design is divisive to the community and must not be done too early. We have all witnessed wars over UIs and toolkits. Our approach will be to provide a level battlefield for those wars.

8. Userland software should always be community projects: Our role at Qi is to accept, understand and process community input, and offer support. Our killer “app” is stable copyleft hardware running stable open low level software. The community we are part of takes that foundation and builds insanely great products.

9. Finish one thing before starting another.

10. Take measured steps in hardware development. A hardware platform that only adds wifi for example will see more focused development that one that adds wifi, GPS, GSM, Bluetooth etc etc. Too much hardware can actually defocus the community efforts and everything is half done.

Personal tools
Namespaces
Variants
Actions
Navigation
interactive
Toolbox
Print/export