The Cathedral & The Bazaar
This is one of these books that it took me forever to get hands on in order to read. I first was made aware of it while watching "OS Revolution". It is basically a set of essays by Eric S. Raymond, of which the titular "The Cathedral and the Bazaar" was at the time the most important, even if not necessarily the most interesting for reader in year 2023. The essays - with one exception - are definitely worth reading, so the book is definitely worthy. Is it must read? Perhaps.
Verdict: perhaps must read.
- A Brief History of Hackerdom - Eric lived through emergence of hacker culture in US that led to formation of Free Software movement. I've never read much on the subject outside of random articles on the internet and Wikipedia entries. What makes Eric insight unique is that not only he actually experienced them from inside. Not all of them but he contributed to GNU, he played with ITS, he was in Unix camp etc. It's definitely worth reading. These are our intellectual and craft forefathers. There are some specific points I'd like to write down for my future reference:
- ITS - whether superior to Unix or not - was doomed by being written in assembler. There was no way to port it - it died with hardware. Whether Unix was superior at the time or not (maybe it wasn't - actually), it's killer feature was C code base
- Emacs was bigger than I thought and initially was written for ITS.
- Sun initial business model was Unix plus workstations for corporations. I vaguely remember the term workstation from my earlier years, but it was essentially dead by the time I entered workforce.
- Networking, so ARPAnet, was key factor in growth. That was something that I will never experience as internet is just too ubiquitous but these faulty network interconnections proved superior to any other way of community building. Even at the time, newspapers were too slow. That's why bigger communities around MS DOS never flourished.
- HURD failed harder than I thought. I thought Linux was just faster. HURD just collapsed under its own development weight. Whether that was because it was too ambitious - as RMS claims - or simply the design process couldn't handle it - as Eric claims - we will never knew. As usual - most likely multifactor failure.
- Fragmented Unix ecosystem was an actual problem at the time. It's interesting parallel that while Linux managed to focus OS community on one kernel, and works more or less quite well for server space, the amount of distros is just as much of an issue for desktop. It feels like X and multiform go hand in hand.
- BSD Unix was named after company (Berkeley Systems Design, Inc.) not University of Berkeley. My bad. Still, the company distributed sources. And...
- Why company backed BSD Unix was less popular than Linux? It's complex story so I will write it down, though it required external reading (so it goes beyond book notes). ITS died because Assembler. Unix thrived thanks to C. Unix fragmented. BSDI emerged as one of the major Unixes and they eventually released full operating system under open license. It was Net/2 BSD and the license is old version of BSD license. It was not license good enough for FSF but would have been for OSI - except OSI formed almost a decade later. It was 1991. GNU tried to build kernel since mid 1980s. And failed. Then they tried GNU HURD since 1990. AT&T attacked BSD Unix with IP claims on court and it took until 1993 to dismiss charges. The fact that BSD was organized in cathedral way was additional hindrance. Linux started being distributed in late 1991 - GNU HURD at the time was nowhere near being usable while Linux quickly was. Here also way of working kicked in with HURD being the Cathedral and Linux being the Bazaar. HURD design choices were impacted by certain underlying bad decisions. Linux was lucky by standing only on its own feet, even if the kernel started as a MINIX rip-off (I'm NOT saying it was but according to Eric, Linux essentially started as MINIX with elements of MINIX being rewritten one by one. So by the end of the process it was fully 100% Linus code; it's smart way of doing this). So where is MINIX in this story? MINIX was released few years before Linux. It was working. But as it was basically support tool for teaching OS development, it was never released in such a way to allow building on it via GPL licensed codebase - its life at the time was tied to a book, and it was publisher call. So by 1993 Linux was widely popular for quite some time, stolen hearts and minds of soon-to-be-named-Open-Source-community, worked with GNU tooling, was more permissive to use than MINIX, was never stuck in court as BSD and was not flawed as HURD was. Also it was not commercial like UNIXs of the time and was not written in Assembler. Indeed, Linux was like penicillin - it was marvelous accident, but it needed someone truly remarkable to pull it off.
- The Cathedral and the Bazaar - the titular essay. The premise was simple. Eric stumbled on the way Linux was developed and couldn't believe it was working as it was exactly what conventional wisdom at the time (and tbh - for the most part still is) said should not work. Then he channeled the learnings into personal experience when he took over small open source project called fetchpop that eventually became fetchmail. Eric decided to try Linux way of developing to his great satisfaction, even if outside opinions on the project where less then reassuring. Eric makes a number of observations, and while they are closer to common knowledge, there's still some interesting insight:
- treating your users as co-developers is your least hassle route to rapid code improvement and effective debugging - sure
- release early, release often - sounds like XP mantra
- often the most striking and innovative solutions come from realizing that your concept of the problem was wrong - they should put it on the posters in software development rooms; and on DDD conferences
- when writing gateway software of any kind, take pains to disturb the data stream as little as possible - kind of obvious, and yet...
- there are some sections discussing usability of management in corporations as opposed to what open source does... which is kind of interesting, but I really think Eric is battling oversimplified vision of something he knows little about.
- Finally in epilogue Eric summarizes the impact of his essay on people in Netscape, leading to Eric Hahn (CTO) releasing source code of Netscape Navigator to the community. It's interesting that overwhelming narrative is that it was a battle of open source vs proprietary, whereas it was really a call to take advantage of free help, being a gamble only because nobody really knew how it works.
- Homesteading the Noosphere - I'm no expert but noosphere is basically space of ideas and reasoning that can be taken over. It's a concept that basically nobody uses outside of small subset of academic circles - and Eric apparently. Homesteading - on the other hand - is a reference to how land ownership worked on the frontier, which apparently is called Lockean theory of property:
- You can take over land nobody owns by claiming and working it
- You can explicitly transfer land and
- The land can be abandoned by not being utilized in any way
These days, we can see is that i.e. forking is used as defensive mechanism against commercial takeover (MariaDB being probably most prominent example), that individual ownership is living just fine side by side with entities like Linux, Mozilla or Apache foundations (foundations are something that Eric deems inferior setup, because he missed they are compromise between corporations and individuals). Yes, the insight is imperfect, but it is always easier with the benefit of hindsight.
Furthermore Eric discusses motivations of hackers (why hackers contribute, in the first place), how open source projects function, what are social norms, what is unwritten code of ethics.
The essay is good read, although I worry that - as generational culture shifted - it is more of a historical artifact, then current reference. - The Magic Cauldron - this essay is trying to analyze open source on the grounds of economics. Eric - while certainly smart guy - is in my opinion out of his depth here. Does he make some good points? Certainly. Is his reasoning at times at least questionable? Well, also certainly. It is somehow too simple and too complicated which is usually hard to pull of when intended, but almost always sign of flawed creation. I recommend just ignoring its existence.
- The Revenge of the Hackers - like the first one, this essay is mostly historical in nature, and as such - quite interesting. It is recounting more recent events, although in all fairness, they feel quite distant now. It starts by quoting infamous Microsoft memo, stating how OSS poses a threat to the company (there was similar memo stating that Java poses a threat as well, by abstracting out Operating System in browser). So it starts where second essay ended - Netscape decided to make source code of Netscape Navigator public. Then it goes through events seen by Eric as one of the major actors. The issue with Free Software (problem with bad associations of word 'free' in US - which is funny, how distorted these perceptions are there), with starting of Open Source Initiative, which Eric was first president (for 7 years or so). Eric presents rationale for why he became spokesperson for the community which didn't like spokespeople in the first place - which I genuinely buy. He was the right person in right place at the right time. The essay ends with Into the Future section - the future which is now past. It is rather amusing to read
Comments
Post a Comment