Note:

• Click on the image above to see the catalog entry.

Recommendation

A very good book.

If you want to hear the case for Open Source versus the free software movement and versus closed-source commercial software, get this book. Raymond puts forth his case strongly and clearly. The book marks a turning point in the history of Open Source and is worth reading on that basis alone.

On the other hand, If you want a book that gives many different Open Source positions, I suggest reading "Open Sources: Voices from the Open Source Revolution".

Of course, if you just aren't interested in Open Source at all, likely you'll not want to read this book or even the details of this review.

Chapter Titles

• 1. A Brief History of Hackerdom
• 2. The Cathedral and the Bazaar
• 3. Homesteading the Noosphere
• 4. The Magic Cauldron
• 5. Revenge of the Hackers
• A. How to Become a Hacker
• B. Statistical Trends in the Fetchmail Project's Growth
• C. Notes, Bibliography, and Acknowledgements

Notes:

• Chapter 1 corresponds to the 2nd chapter in "Open Sources".
• Chapter 5 corresponds to the last chapter in "Open Sources".

A Bold Prediction

In the afterword of this book Raymond makes the following prediction: "I expect the open-source movement to have essentially won its point about software within three to five years (that is, by 2003-2005)."

Notes:

• Unfortunately, he doesn't specify the criteria for open source being said to have won its point.
• That being said, Linux does seem to have a healthy percentage of the server market.
• And Linux distributions are making inroads on the desktop too.

Some Bazaar Insights

Here's some insights, highlighted in the book, that support the Bazaar style of development

• Good software begins with the developer addressing a problem the developer personally has
• Treat users as co-developers.
• Release early and often. Listen to customers.
• With a large enough group of co-developers, nearly every problem will be quickly characterized and solved.
• Beta testers are your most valuable resource if you treat them that way.
• Recognizing good ideas is sometimes even more important than having them.

Note:

• All the above insights (and more) are highlighted in the second chapter.

Linus's Law

• "Given enough eyeballs, all bugs are shallow."

[top]

Notes:

• This is one of the penguin Logos Linus Torvalds says he likes
• used with permission provided I acknowledge Larry Ewing (lewing@isc.tamu.edu) and The Gimp, if anyone asks.

Contents

• What's the Cathedral?
• What's the Bazaar?
• About the Reviewer
• Limitations of the Review
• Am I Hacker?
• The Problem with the Cathedral
• The Merits of the Bazaar
• The Saint in the Belfry

Notes:

• I read and reviewed this book on-line using Safari.
• In fact I don't own or have easy access to a physical copy of this book.

Notes:

• Published by O'Reilly.
• Click on the image above to see the catalog entry.

What's the Cathedral?

As best I understand, what is being talked about here is a style of software development characterized by:

• centralized design by one person or a small group
• a limited number of contributors
• occasional carefully controlled releases
• a relatively small amount of interaction with people outside the core group.

Actually, Raymond spends very little time focusing on this approach. His main focus is on Bazaar style development, which we'll get to in a moment.

But the style is certainly familiar. Indeed most of the corporate software development projects I've worked on have been variants of this style.

[top]

What's the Bazaar?

The Bazaar style of software development is quite different and is characterized by:

• a gatekeeper who can recognize good design contributions from others
• many developers (often part time) scattered all over the globe
• early, frequent releases
• getting a lot of feedback from customers who are knowledgeable programmers and have access to the code

The on-going development of Linux is an excellent example of this style. The style may seem chaotic, but has turned out to be surprisingly effective.

See "Some Bazaar Insights" for some (duh) insights related to this style of development.

[top]

About the Reviewer

I started using MACs in 1988, and for a long time, I used a MAC as my primary computer at home. I've been using various forms of Unix since 1989. In 2002, I shifted to using Linux on a PC for nearly all of my home computing.

Since 1994, I've been a user of Perl and an advocate of Perl and Perl culture. I like the way that Larry Wall (the creator of Perl) thinks about a variety of subjects.

It's only recently that I have become seriously interested in the issues revolving around Open Source. I've read and reviewed the book "Free as in Freedom" which relates the story of Richard Stallman's spearheading the Free Software Movement. I've also read and reviewed the book "Open Sources: Voices from the Open Source Revolution" which includes many authors with a spectrum of Open Source perspectives. "Open Source" includes two chapters that are also in "The Cathedral and the Bazaar". Although I'm in the process of settling on my point of view regarding Open Source, I am clear that I am in favor of it.

If you for some reason feel more about me would serve you, a good starting place might be the home page of my personal site.

Some of my motivations for reading this book were

• to learn Raymond's position regarding Open Source
• to hear why he favors the Open Source over the Free Software Movement
• to find out what he meant by the very kool title "The Cathedral and the Bazaar"
• to learn more about hackers

[top]

Limitations of the Review

Some things that I'm aware of that may limit the value of this review to you are

• I haven't read previous edition.
• I began engaging with the issues raised here fairly recently.
• My tentative position on Open Source is much closer to Larry Wall's than to Raymond's.
• I don't own or have easy access to a physical copy of this book. I read an electronic copy of this book on Safari.
• I am not an economist, anthropologist or computer scientist. Nor am I a CEO.

A look at what I say above in "About the Reviewer" will likely suggest other limitations, biases, etc.

[top]

Am I a Hacker?

I'm quite aware that you likely don't much care if I'm a hacker or not. But engaging with that question will give you a hint of how much (a lot) there is in this book about hackers and hacker culture. And it will keep me engaged, ok? This apparent excursion also reveals an interesting issue that may be of interest to some.

based on the definition in the preface: Well, in the software world, I'd say I'm an enthusiast, an artist, a tinker and a problem solver. All of which we're told is part of the original meaning of hacker.

But I'm not part of the partisan tribe that built Unix, the World Wide Web and Linux. Nor have I been involved in the development of any other open source software. Oh, well.

based on chapter one: Well, let's see. I certainly have done a lot of programming in various assembly languages, a lesser but still substantial amount in FORTRAN (yuck), and I've also done substantial coding in a number of other languages. And I've done a significant amount of coding in octal (yek), though I've never toggled any code in through front panel switches. I even at one time wore polyester suits and ties as my standard work attire. And I've worn glasses since I was a kid. All this fits closely with what Raymond says about hackers.

But I don't have a background in physics or engineering. I wasn't an amateur radio enthusiast. Hm, I didn't used to wear white sox either; but sometime after giving up the polyester suits I started wearing them; maybe I'm playing catchup. Running shoes and white sox are really comfortable and easy to take care of.

appendix a: There's a whole appendix on "How to Become a Hacker". I am hoping this appendix is offered with tongue in cheek. I sure hope no one reads it and says "Oh, kool, here's the blueprint. I think I'll become a hacker." A depressing way to live, and likely not the way that true hackers are born. But whether or not the appendix is intended to be taken lightly, there's useful information there.

One of the things that Raymond tells us in the appendix is that for a hacker whether something is interesting and whether a solution is good is generally determined by the hacker's technical peers and superiors. My point of view is quite different. Whether something is interesting I generally evaluate primarily in terms of myself and people I am or might be doing things for. The opinions of other programmers are not irrelevant, just less important in most cases. Whether a programming solution is good is for me mainly determined by whether it satisfies the need or opportunity it was created in response to, by the customer and by the user. So in this regard too I'm not a hacker.

In my opinion, this difference is major. I do not see it as a merely theoretical difference. As far as I can tell there are a significant number of programmers who resent that there are users who may not think the same way they do. I am not one of them.

personal conclusion: In the context that Raymond is talking about I'm definitely not a hacker; In fact in the sense he focuses on, I definitely prefer to not be a hacker. In a more general sense of enthusiast, artist and problem solver, I am a hacker of several kinds, including being a software hacker.

conclusion regarding the book: There's a wealth of information here about the hackers and hacker culture that led to the creation of Unix, the World Wide Web, Linux, etc. You don't just learn about what a hacker is, you also learn a great deal about the history and dynamics of the hacker culture, and more. Hey, two of the five chapters plus an appendix all focus on hackers.

[top]

The Problem with the Cathedral

Well, the biggest problem with the Cathedral style of development is that it simply doesn't take advantage of the efficiencies of Bazaar style development and its ability to effectively take advantage of a large developer base. (See "The Merits of the Bazaar" below.) This is true whether the software is commercial or not.

There's an additional concern that Raymond has regarding many proponents of the free software movement and that has to do with the way they sometimes frame their argument in favor of Open Source. They bring in social considerations which Raymond believes is unnecessary and only confuses the issue.

Raymond believes that the Open Source development model is clearly more efficient than traditional approaches and that bringing up social arguments is counterproductive. He believes the argument for Open Source can be won without them.

[top]

The Merits of the Bazaar

Raymond claims that the Bazaar method of development is the most effective ever developed and provides theories and evidence to support that claim.

Some important factors in the success of this method are

• the existence of significant numbers of hackers who are technically competent
• the existence of the hacker community they are part of which is optimized for creating high quality creative work
• Linus's Law: "Given enough eyeballs, all bugs are shallow."
• the availability of source code for all to look at and play with
• the availability of the Internet for communication

The Bazaar method of development takes advantage of Linus' Law and hackers from the hacker community who have access to the source code communicating over the Internet (or some such). It goes through release-test-fix cycles incredibly quickly and produces high quality results in a short time frame. Partly it achieves this by giving up trying to force programmers to produce on fixed schedules.

Well, that's a crude simplification (or transmogrification?) of what Raymond says. The book, however, goes into considerable detail about how the various factors work together to produce unprecedented results.

economics of: But is Open Source economically viable? In the fourth chapter of this book Raymond explains how and why the economics of Open Source really do work. He shows how it can work in either a profit or a non-profit context.

preconditions: But Raymond is not recommending Bazaar style development for everything. More specifically, he doesn't recommend Bazaar mode for originating a project.

One major precondition of Bazaar style development is having something to start with that

• is runnable and testable
• shows promise of evolving into something kool in the foreseeable future.

Another precondition is that you need a leader/coordinator who

• can recognize good design ideas from others
• can attract people to the project and keep them happy

[top]

The Saint in the Belfry

One of my motivations for reading this book was to find out Raymond's argument against Stallman and the Free Software Movement. When I look from one point of view, it appears that Raymond has driven a steam roller over the Free Software Movement. (See "The Merits of the Bazaar" above.) But when I look from another point of view, it appears that Raymond has failed to seriously address the position of the Free Software Movement.

When I refer to the Saint in the Belfry, I'm referring to Richard Stallman and what he represents. While Raymond does mention Stallman (and even acknowledges his contributions more than once) and the free software movement too, he spends little time focusing on their position, and never focuses on it in their terms.

What if you place a significantly higher value on the social issues than on the efficiency issues? What if you if your priority is making software free?

What I hear Raymond saying is: Let us more pragmatic types lead the way. We know how to win this battle. Confine your arguments to matters of efficiency. Be quiet about social issues until we've won the victory for you. Things will surely be better for you then. In time what you really want to say may even be relevant. I'm still grappling with where I stand on Open Source; but if I held what I understand to be Stallman's position, I sure wouldn't be convinced at all by Raymond's point of view.

One might also ask, if one's agenda has a significant social component, wouldn't it contribute to a more open society to make that clear in one's argument. One might even take the position that it would be unethical to do otherwise.

I gather Raymond feels Stallman ideologizes too much. In contrast, he seems to view himself as ashewing ideology, at least for now. I gather that he doesn't consider his particular brand of pragmatism as an ideology. By some definition of ideology I'm unfamiliar with, perhaps not. But in the book he certainly puts forth a vision of the future and theorizes about it a lot and presents a complex system of concepts about the (hacker) tribe he relates to. Raymond makes a strong case for his position, but it seems to me that we have here a case of a pitch black pot calling the kettle black.

But all this may be beside the point since there are likely few people concerned with the social side of these issues.

Still, I do wish Raymond had taken the Saint in the belfry more seriously.

[top]

Final Thoughts

If you've actually read through this review, you are likely quite interested in reflecting on Open Source. Hey, why not get the book and read what Raymond has to say in his own words?

Note:

• Click on the image above to see the catalog entry.