class: center, middle # CSCI-UA 480.10: OSSD <br> ## _The Cathedral and The Bazaar_ by ESR ### Lessons / Aphorisms / FOSSisms .author[ Instructor: Joanna Klukowska <br> ] .license[ Unless noted otherwise all content is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). ] --- class: center, middle ## Who is Eric S. Raymond (ESR)? --- ## Eric S. Raymond: The "Hacker-Anthropologist" - A core developer in the 80s and 90s; maintainer of the [*Jargon File* (the "Hacker's Dictionary")](http://www.catb.org/jargon/). -- - He didn't just write code; he observed *how* people wrote code. -- - He is credited with rebranding "Free Software" (which felt anti-commercial) to **"Open Source"** (which felt like a superior business methodology). -- - *The Cathedral and the Bazaar* (1997) was the first "white paper" that explained why Linux was succeeding despite having no traditional management. --- ## The Origin Story: Fetchmail - Before the essay, ESR believed in the "Cathedral" model (small groups, rare releases). - He started **Fetchmail**, a utility to retrieve POP3 mail. -- - Instead of keeping the code to himself until it was "perfect," he copied **Linus Torvalds’s** style: - He released early and often. - He delegated everything he could. - He solicited constant feedback. -- - **The Result:** The software improved faster than anything he had ever written alone. --- ## The Core Metaphor: ### The Cathedral vs The Bazaar -- ### The Cathedral - Software built by "lone wizards" or small elite groups. - No public access to code until "Release Day." - Examples (at the time): Emacs, GCC, and almost all proprietary software (Windows). ### The Bazaar - A "noisy bazaar of differing agendas and approaches." - The code is public from day one. - Submissions come from everywhere; the "lead" acts more as an editor than a dictator. - Example: The Linux Kernel. --- class: center, middle # The Lessons of the Bazaar ## (FOSSisms/Aphorisms from the Essay) --- class: center, middle ## Every good work of software starts by scratching a developer's personal itch. --- class: center, middle ## Good programmers know what to write. Great ones know what to rewrite (and reuse). --- class: center, middle ## "Plan to throw one away; you will, anyhow." (Fred Brooks, The Mythical Man-Month, Chapter 11). --- class: center, middle ## If you have the right attitude, interesting problems will find you. --- class: center, middle ## When you lose interest in a program, your last duty to it is to hand it off to a competent successor. --- class: center, middle ## Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. --- class: center, middle ## Release early. Release often. And listen to your customers. --- class: center, middle ## Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. or ## Given enough eyeballs, all bugs are shallow. --- class: middle .center[ ## Smart data structures and dumb code works a lot better than the other way around. ] From Torvald's talk about git: " I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. " --- class: center, middle ## If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. --- class: center, middle ## The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. --- class: center, middle ## Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. --- class: center, middle ## "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." --- class: center, middle ## To solve an interesting problem, start by finding a problem that is interesting to you. --- class: center, middle ## Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. --- class: center, middle ## 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! --- class: center, middle ## When your language is nowhere near Turing-complete, syntactic sugar can be your friend. --- class: center, middle ## A security system is only as secure as its secret. Beware of pseudo-secrets. --- class: center, middle ## What comes after? --- ## The "Netscape Moment" (1998) - In 1998, Netscape was losing the "Browser War" to Microsoft’s Internet Explorer. - Executives read *The Cathedral and the Bazaar* and were convinced that the only way to beat Microsoft was to "release the beast." - They released the source code for Netscape Communicator, which led to the creation of the **Mozilla Project** and, eventually, **Firefox**. - This was the first time a major corporation "went open source" based on ESR's theory. --- ## Critical Thinking: Does the Bazaar Always Work? - **The "Eyeball" Problem:** "Given enough eyeballs, all bugs are shallow." -- - *Counterpoint:* What if no one is actually looking? (See: **Heartbleed** in OpenSSL or the **Log4j** vulnerability). -- - **Corporate Influence:** Today, the "Bazaar" is funded by trillion-dollar companies (Google, Meta, Microsoft). -- - **Sustainability:** If a project isn't "interesting" (the "itch"), who maintains the boring but critical infrastructure? --- ## References & Further Reading - **The Original Essay:** [The Cathedral and the Bazaar](http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/) - **ESR’s Memoirs:** [Revenge of the Hackers](http://www.catb.org/~esr/writings/cathedral-bazaar/magic-cauldron/) - **The History:** *Free for All* by Peter Wayner (Covers the Netscape decision in detail). - **The Counter-Argument:** *The Success of Open Source* by Steven Weber (A more academic look at the political economy of FOSS).