Eric S. Raymond

While I'm happy to finally have gotten around to finishing this book, my intent was to read this set of older essays critically now that time has passed since the most exciting times of the Open Source revolution. The Cathedral & the Bazaar was a good essay, and Homesteading the Noosphere was, too, I guess.

As for The Magic Cauldron, I started taking exception to some of the claims. For example, "No software customer will rationally choose to lock itself into a supplier-controlled monopoly by show more becoming dependent on closed source if any open-source alternative of acceptable quality is available." I respectfully disagree. Whereas I would greatly prefer it, and have run Linux on a laptop as my primary desktop, I have found myself going back to Microsoft Windows 7 as my preferred choice. I am not alone in this regard.

There is no doubt that Microsoft has taken some cues from the Open Source revolution and developed better products since this book was written, but there is a lot of Microsoft bashing and hubris that I find often has accompanied Open Source adoption, some deserved, some not.

As for the final section, How To Become A Hacker. I feel the book went off the rails. Whereas Eric S. Raymond states that he is an accidental revolutionary and didn't want the job, he certainly embraced it. I agree with the sentiment that "You are finally a hacker when others call you a hacker," but there is also way too much egoism here. Lines like the following, "Go away, idiot" and "Go to a DOS prompt and type 'format c:'. The problems you are experiencing will cease in a few minutes" do not earn any points with me.

Lastly, the same tired "hacker" versus "cracker" arguments come up again. I'll start using "cracker" instead of "hacker" when people such as the author start using other terminology like using "hypothesis" instead of "theory" correctly. show less

Good book. There were a lot of things in here that I've felt for a long time but was not sure how to explain. For example, the discussion of why config files should be human readable made me realize why I was so opposed to an advisor's suggestion that our config file be a giant ugly s-expression on a project I did last year; it also made me realize why I felt that the backend for that project should use sockets to communicate with the GUI (because it encourages modularity, keeps GUI code out show more of real program logic, allows new interfaces to be easily added, allows GUI to run on a separate machine than the back end; we'd only though of the last). Not all was justification though; I also learned lessons about good ways to format and output errors and how much our testing process sucked. show less

This is a collection of essays which are all available online but nice to have in book form. The common theme through all the essays is explaining, from an insider's point of view, who hackers are and why open source software seems to work so well. Although ESR can sometimes brush off the commercial world (and even the academic world) a bit quickly, his essays feel right to me overall.

I think he is right about why open source software tends to be of such good quality (frequent small show more releases, users encouraged to submit bugs and become part of the developer community, peer review). However, I think it is going a bit far to say that the factors which make OSS good also make closed source bad.

One area where the analysis does seem to be right on is his discussion of why people contribute to open source. The short version is that people contribute to open source because they have a need or an interest in the problem, but they continue contributing in open source because they build up a reputation. This reputation is not for themselves, but for their code and other work. No one can be an open source coder for the reputation, but the reputation is the community's way of letting developers know that their work is being used and appreciated. One way to think of it is that reputation lets people know there is value is working for others, not just themselves.

Anyone who participates in code development should read this book. show less

If you are interested in the roots of open source, this is a great read. The book is a collection of essays, with The Cathedral and the Bazaar being the best essay by far. The Brief History of Hackerdom + Revenge of the Hackers are interesting historical accounts; Appendix A is instructional for the clueless (and a pleasant refresher for the “part-time” hacker). The rest is, for the most part, an exposé into the hacker culture and is definitely worth reading.

A grain of salt. Some of the show more conclusions the author makes seem to be problematic, at least in my opinion. The author often compares the hacker community to the academic research community, but fails to follow one of the key requirements in science, which is to question one's results. Consider this: "Having established that prestige is central to the hacker culture's reward mechanisms, we now need to understand..." (p. 89) - this follows a section where the author actually *fails* to find evidence directly supporting his proposition: "many hackers ... show a strong reluctance to admit that their behavior was motivated by a desire for peer repute..." (p. 88). In academia, we would not state that our subject "failed to admit" something - because that implies that we know for a fact that our subject is "guilty", which begs the question: why even ask the subject? Why bother with doing research?

However, this is not a research paper - so what’s the big deal? To me, here’s the big issue: the author repeatedly refers to himself as an ethnographer, mentions qualitative research method, speaks of developing and testing theories, and makes frequent references to a variety of concepts from the social sciences. As a result, the essays read more like research reports, which we expect to be impartial accounts supported by systematically collected and analyzed data. Which is not really the case here.

That said, the essays offer useful insights, as well as memorable one-liners - such as "smart data structures and dumb code works a lot better than the other way around" or “every good work of software starts by scratching a developer's personal itch” - which are a delight to read for any programmer. show less