The Cathedral and The Bazaar

Revisiting the Open Source Software classic

20 years ago, Eric Steven Raymond typed The Cathedral and The Bazaar,a classic open-source story. It distinguishes between two distinct styles of development.

• Cathedral:Software carefully and quietly crafted by individuals within an isolated, mostly secret development team.
• Bazaar:Chaotic, babbling open source development, miraculously coherent amongst both the signal and the noise of the crowds.

As Gitcoin grows at the intersection of OSS and blockchain, two communities which stand on the shoulders of pioneers like Mr. Raymond, we thought it was timely to republish the main lessons from his tale of building Fetchmail (a POP protocol improvement) via the Bazaar approach.

Lessons For Building A Bazaar

As Raymond built Fetchmail, he intentionally emulated Linus Torvalds open source development approach to building the Linux operating system. Along the way, he hoped to test the theories he had been developing about the ‘bazaar style’ as he observed the surprising success of Linux in the 1990s.

Fetchmail, too, turned out to be a success.In Raymond’s story explaining the development process of the product, he stops early and often to reflect on lessons he learned. These lesson have since been immortalized in Open Source Software — perhaps even outlasting Fetchmail itself. Without further ado, here goes:

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 (version) one away; you will, anyhow. [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. (Rewritten: “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.

For those interested, these lessons are illustrated vividly through Raymond’s original piece, available here (and open source — who would have guessed?).

Bazaar’s in Blockchain

The world of blockchain is increasingly intersected with the world of open-source. Most blockchain protocols and applications are open source. It is, thus, important for those in the space building the next generation of bazaar’s to keep in mind the lessons helpful to our open source predecessors.

Today, we believe Gitcoin helps incentivize open source workers like never before. If Linus Torvalds could build Linux and Eric Raymond could create Fetchmail in a world before blockchain based financial incentives (alongside the great characteristics OSS brought to the table), what may we be able to create next? This is the future we imagine and are building towards.

Read The Cathedral and The Bazaar (20 min read)

Lessons above are directly referenced from the Cathedral and the Bazaar — Copyright© Eric Raymond, 2000.

This post is Part II in a series of posts by the Gitcoin team entitled “Pushing Open Source Forward,” exploring the intersection of Open Source and Blockchain — which draw heavy inspiration from the bazaar approach.

• The History Of Open Source
• The Cathedral & The Bazaar
• OSS Giants & Their Impact
• Issues With Traditional OSS
• Push Open Source Forward

To contribute to the conversation or learn more about Gitcoin, find us around the interwebs on Slack, Twitter, or Github!

https://gitcoin.co/