AB’s reflections

I’ve been interning at Sun Microsystems in Delhi from May 1st and during this period, I’ve had the opportunity to research a variety of open source applications. My initial project was to explore and research various open source applications suitable for use by students and compare them against each other and with the proprietary alternatives. There are indeed a bunch of alternatives available for the software we use during the course of our day to day work.

I managed to submit a paper on “Components of an Open Source Operating System for Sustainable ICT Education in Schools in Developing Countries” to the HICSS conference, and I’m starting off a multi part post with my learnings on open source software and development.

One of the interesting works that I read on open source development was Eric Raymond’s “The Cathedral and The Bazaar”. This is probably one of the definitive works on open source development, and a number of theories stem from it. In fact, quite a few papers that I referred to during the course of my research cited this work. He has postulated the following principles in the essay:

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.
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. (The full version of Linus’s law – Given enough eyeballs, all bugs are shallow)
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.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Most of his principles are for software development in general, and so also apply to open source development. The key learnings form his essay are two-fold. First is that it is important to have a working prototype of the project before making it open source, or at least trying to find other developers who’d be interested in it. Second is that open source attracts a wide variety of talent that can be put to various uses, ranging from bug finding, to improvement suggestions to actual coding. Thus, it is essential to treat the participants in the right manner as everyone could make an important contribution.

One of the other observations to be made about open source development is the vital role that the internet has played in creating the synergy that exists between the developers, users and other contributors of any open source project. In fact, Eric Raymond has said as much in his essay:

… Another (in hindsight) was that the Internet wasn’t yet good enough.

Before cheap Internet, there were some geographically compact communities where the culture encouraged Weinberg’s “egoless” programming, and a developer could easily attract a lot of skilled kibitzers and co-developers. Bell Labs, the MIT AI and LCS labs, UC Berkeley—these became the home of innovations that are legendary and still potent.

Linux was the first project for which a conscious and successful effort to use the entire world as its talent pool was made. I don’t think it’s a coincidence that the gestation period of Linux coincided with the birth of the World Wide Web, and that Linux left its infancy during the same period in 1993–1994 that saw the takeoff of the ISP industry and the explosion of mainstream interest in the Internet. Linus was the first person who learned how to play by the new rules that pervasive Internet access made possible.

In essence, open source development has a lot of potential when used in the right manner. In fact, many companies use it quite strategically and couple them with interesting licenses (I’ll cover licenses in another part). There are also quite a few organizations championing free (as in freedom) software with the FSF (Free Software Foundation), headed by Richard Stallman being one of the pioneers. There is also a bit of controversy in the Free/Open Source world with some preferring the term free to open source. This has however not deterred organizations from leveraging open source development strategically. Open source development may not be practicable in every situation, particularly for routine software development in enterprises, but it definitely has its merits and I’ll be looking at other aspects of open source software in subsequent parts.