- Fight by Software Programmers for their Rights – the beginnings
- Some Attributes of Good Software and Great Programmers
- Users as Co Developers OR The Secret of Programming Success
- You Do Agile Development? Open Source?
- Don’t Read if you are not a Developer
- Nurturing a small software project to success
- The Truth Behind Genius
- Listen to your users!
- “What Language?” – For humans or For computers?
- Charming Developers to Make Great Software
- Democratic Centralism for Organizing Groups
- Recruiting the Best for a Project
- Chrome, Firefox, Mozilla browser engines – The beginnings
The 3rd part of The Cathedral and The Bazaar by Eric Raymond.
Genius is not in the lonely isolated genius sitting in his jungle house. Genius of a good product lies in collaborative efforts by many interested individuals. Eric Raymond explains this principle citing the development model of Linux, GNU Lisp, Emacs VC mode and MATLAB.
In short, knowledge, creativity and use value come from collaborative effort of knowledgeable, hard working individuals, not merely out of individual brilliance.
The Importance of Having Users
And so I inherited popclient. Just as importantly, I inherited popclient’s user base. Users are wonderful things to have, and not just because they demonstrate that you’re serving a need, that you’ve done something right. Properly cultivated, they can become co-developers.
Another strength of the Unix tradition, one that Linux pushes to a happy extreme, is that a lot of users are hackers too. Because source code is available, they can be effective hackers. This can be tremendously useful for shortening debugging time. Given a bit of encouragement, your users will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently.
In fact, I think Linus’s cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: “I’m basically a very lazy person who likes to get credit for things other people actually do.” Lazy like a fox. Or, as Robert Heinlein famously wrote of one of his characters, too lazy to fail.
In retrospect, one precedent for the methods and success of Linux can be seen in the development of the GNU Emacs Lisp library and Lisp code archives.
In contrast to the cathedral-building style of the Emacs C core and most other GNU tools, the evolution of the Lisp code pool was fluid and very user-driven. Ideas and prototype modes were often rewritten three or four times before reaching a stable final form. And loosely-coupled collaborations enabled by the Internet, a la Linux, were frequent.
Indeed, my own most successful single hack previous to fetchmail was probably Emacs VC (version control) mode, a Linux-like collaboration by email with three other people, only one of whom (Richard Stallman, the author of Emacs and founder of the Free Software Foundation) I have met to this day. It was a front-end for SCCS, RCS and later CVS from within Emacs that offered “one-touch” version control operations. It evolved from a tiny, crude sccs.el mode somebody else had written. And the development of VC succeeded because, unlike Emacs itself, Emacs Lisp code could go through release/test/improve generations very quickly.
The Emacs story is not unique. There have been other software products with a two-level architecture and a two-tier user community that combined a cathedral-mode core and a bazaar-mode toolbox. One such is MATLAB, a commercial data-analysis and visualization tool. Users of MATLAB and other products with a similar structure invariably report that the action, the ferment, the innovation mostly takes place in the open part of the tool where a large and varied community can tinker with it.
(Continued –Click here to read the other parts )