Applying the Open Source Model

I am somewhat of a computer geek so friends often use me as their help desk. In 2000, a friend was looking to start up an internet cafe and asked me if I had ever looked at Linux and would it work for the back end of an internet cafe setup? I had never looked at it but agreed to do so. I installed RedHat on an old machine I had sitting in the closet and began my journey into the open source world. I used my Linux box as my file backup machine for a couple years and played with it in my spare time. Over time, I came to use it more and more and in 2002 when I was re-installing Windows 2000 on my machine for the 3rd time in a year because some software screwed up the whole system, I stopped and installed Linux instead, I have been using it ever since.

Watching Linux "grow up" and become a viable replacement for the Windows desktop, I have always been amazed at the stability, speed, and dramatic rate of improvement of software. I have learned a lot about how it is developed and deployed although I can barely program an excel macro. This is such a great development model, why can't we take it out of the software world and use it for other things? So this is my experiment at doing so. Manufacturing reliability has been around for 60 years or so but so few companies have effectively implemented it and it intrigues me. To compete in the global economy as a manufacturer, you have to be reliable. Things get commoditized so fast today that the only way to compete is to be reducing your costs faster than everybody else so you maintain the highest margins.

Borrowing from the rules of Eric Raymond in The Cathedral and the Bazaar I will attempt to follow his rules here:

1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.

While some of these are fairly software specific, most translate into this application. Here is my best attempt to translate:

1. Every improvement starts with scratching somebody's personal itch.
2. Good initiatives apply the best of what is out there vs re-inventing it.
3. Plan to throw away one iteration and start over at least once. You will anyway.
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program (initiative) your last duty is to hand it off to a competent successor.
6. Treating the user/customer as the co-author/developer is the easiest way to rapid development.
7. Release early. Release often (everything is beta). Listen to what your customers say and make improvements.
8. Given a large enough group of beta-testers and co-developers, every problem will be characterized quickly and the fix will be obvious to somebody.
9. Simple work processes and clear hand offs work a lot better than complex, elegant procedures [rough translation].
10. If you treat your users (beta-testers) as if they are your most valuable resource, they will become your most valuable resource.
11. The next best thing to having a great idea is recognizing great ideas from others. Sometimes it is better.
12. Often the most striking and innovatinve solutions come from realizing that your concept of the problem was wrong.
13. "Perfection" in design is achieved not when there is nothing more to add but rather when there is nothing more to take away.
14. Any tool should be useful in the expected way but a truly great tool lends itself to uses you never expected.
15. When transferring information to others, take great pains to transfer as accurately as possible and don't throw away information unless the recipient forces you to.
16. Does not really translate
17. Does not really translate
18. To solve an interesting problem, start by finding a problem that is interesting to you.