The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary

by Eric S. Raymond

Open source provides the competitive advantage in the Internet Age. According to the August Forrester Report, 56 percent of IT managers interviewed at Global 2,500 companies are already using some type of open source software in their infrastructure and another 6 percent will install it in the next two years. This revolutionary model for collaborative software development is being embraced and studied by many of the biggest players in the high-tech industry, from Sun Microsystems to IBM to Intel.

The Cathedral & the Bazaar is a must for anyone who cares about the future of the computer industry or the dynamics of the information economy. Already, billions of dollars have been made and lost based on the ideas in this book. Its conclusions will be studied, debated, and implemented for years to come. According to Bob Young, "This is Eric Raymond's great contribution to the success of the open source revolution, to the adoption of Linux-based operating systems, and to the success of open source users and the companies that supply them."

The interest in open source software development has grown enormously in the past year. This revised and expanded paperback edition includes new material on open source developments in 1999 and 2000. Raymond's clear and effective writing style accurately describing the benefits of open source software has been key to its success. With major vendors creating acceptance for open source within companies, independent vendors will become the open source story in 2001.

Genres: Nonfiction, Programming, Technology, Computer Science, Computers, Business, History

241 pages, Paperback

First published October 1, 1999

About the author

Eric S. Raymond is an observer-participant anthropologist in the Internet hacker culture. His research has helped explain the decentralized open-source model of software development that has proven so effective in the evolution of the Internet. Mr. Raymond is also a science fiction fan, a musician, an activist for the First and Second Amendments, and a martial artist with a Black Belt in Tae Kwon Do.

--from the author's website

Reviews

[Philipp · Rating 3 out of 5]

This book describes two 'modes' or 'metaphors' for software development - the old 'Cathedral' one, in which a few programmers, locked away from the world, slowly release iterations of their software to the world, a mode employed by the business world. Then there's the new 'Bazaar', in which rapid development around a core team of developers is favoured, developers who are constantly in contact with users and co-developers - most of open source software development happens like this.

It's an interesting time-document that directly led to the founding of what's now known as Mozilla, but it's also outdated. Reading the arguments I couldn't help but constantly think 'but what about Heartbleed?' for most points - for those few who haven't heard of it, Heartbleed is/was a huge security bug in the widely used openSSL library that enabled attackers to read arbitrary memory of any SSL-enabled webserver.

Especially towards the end the book builds up a few straw-men to take down, and then it gets annoying - like when the book says that 'Bazaar' style development doesn't need the business (Cathedral) world's top-down style management, because open source is just so much fun that it doesn't need managers! 'But what about heartbleed?': the OpenSSL code is such a notorious mess that for years developers who wanted to fix any problems recoiled as if encountering a Lovecraftian horror, quickly abandoning their good intentions to save their sanity. The argument of 'many shallow eyes see all important bugs' obviously didn't pan out, the bug existed for years.

Only now are some openBSD people working on fixing OpenSSL in LibreSSL, but for them it's a concerted effort with 'management' involved, so it seems to be some kind of chimera between Bazaar and Cathedral, in which only very few 'outsiders' are involved.

I guess Bazaar style development doesn't work that well for security relevant software; it's insanely complicated and there are too many 'bad' agents (like the NSA) who can act as good 'customers of the Bazaar'.

But it still goes some good points here and there, like for example this one:

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

It's a quick read, I'd recommend it to all open source programmers interested into seeing where their hobby comes from.

UPDATE 30.12.2014: I just found this longer good essay revisiting the main points of the book, quote:

That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution. (Sic transit gloria mundi, etc.)

Recommended reading!

[Joe White · Rating 4 out of 5]

As the Bible of the Open Source definition, this is a 5 star book. It also happens to be one of the few ever written which attempts to explain what open source is and define its motives and mechanics.

The issues I see with the book, which are being put forth from my own opinion 15 years after the books writing date and 12 years after this version's last update are these:

1. It too lightly sidestepped the issues surrounding the introduction of a new software version number. The statements and assumptions are that bugs in a new version will be seen and fixed quickly, and that a project will be forked if it represents a change in direction not desired. The scale of an application is important in determining whether either of these actions will occur. The management of the project control structure also plays a very significant part in determining what happens with bug fixes and a software cycle. In the decade after the book's publication, Red Hat dropped its "boxed" desktop and desktop end user support. While this was not cataclysmic, it did take about four years before Fedora was able to install and run smoothly on my hardware at the time. Twelve years later, Fedora may now have returned as the most acceptable desktop version to support KDE and bleeding edge development software. That four year downturn interval would have been a problem except for the fact that there were alternative distributions as good or better. I used SUSE at the time. Now, 12 years later, the two major desktop applications have had periods representing major disruption. The KDE group decided to do a complete rewrite of their software - both desktop and application at version 4.0. This was a very buggy version which required a change in interaction with the desktop. It has taken almost 5 years to correct most of the bugs and bring the vision for that desktop experience to a level for the average user to appreciate. Four and five year intervals are a long time in any software cycle, and too long for instability for a dedicated user. By the way - KDE was criticised heavily and lost a lot of users but was never forked and never had a larger number of eyeballs fixing problems. Now the Gnome desktop has performed the same over-the-cliff magic of a major disruptive change in application desktop use underscored partially by the need for a re-write, but also partially to accommodate the growing need for touchscreen application use and also because of the belief of its main developers to simplify the usage of the desktop. In this case, the Gnome desktop shell has been forked, and is being modified in separate stream versions, but it has represented a major disruption in the configurability and interaction with the desktop. When written, the book represented Linux and Mozilla in their early growth and stabilization phases. In a more mature phase, open source is not shining to either established or new users due to the lengthy time disruptions of large scale critical systems.

2. Throughout the last decade and increasingly today, monopolistic enterprises are surviving well in the US court system and are impeding open source just as effectively as ever. Apple is an extensive user of open source and has even been a major sponsor of important projects. Apple is also as closed as any company has been in regard to freedom of use of its products. Microsoft's failures and new OS releases have barely slowed its growth and level of use. It still controls hardware vendors, almost none of which ship with Linux as an OS, and none of which include competitive tools such as Libre Office, or Firefox. The prediction in the book that Windows 2000 would be a major disaster was just unrealistic.

3. A lot of open source startup companies have been purchased and squashed by major corporations. Novell acquired SUSE, but has since floundered. openSuse has been freed, but also suffered from the swings of ownership. Oracle has had numerous purchases, most visibly Sun, which has had an impact on Java, MySQL, and OpenOffice. There are many other examples out there. This type of competitive development wasn't really covered in the Raymond book.

4. Not foreseen at the time of its release, the book doesn't address the growth of Mobile devices which stimulated the use of "Apps" and "App stores". Open source is really being squeezed in this new environment. IOS has a vertical application scheme including licensing and distribution costs. Android is being developed as closed source before release, and seems to have many limitations. For example there is not an effective up to date x86 version of Android that can be conveniently run on any desktop. While the Android SDK kit and emulator are freely available, they may not produce the same result at the hardware level that is see in the emulated environment. Google controls this interface, and as far as I am aware there are no alternative development tools or runtime test environments.

5. Being too critical two decades in hindsight is not fair, but near the end of the book it was approaching an evangelistic tone, which as a dedicated open source user for the last 12 years, I feel needs to be a moderated message in the face of massive FUD campaigns and limited uptake by general users who don't have the need and will never understand development models. Those average users consider themselves as very tech savvy if they can manage a 1 button device, configure colors on it, and perhaps load a few presented software app choices. The capacity to have the freedom to innovate takes a lot of work and is a constant struggle against monopolies in this market. I think that one failing of the Raymond outlook is that it was overly optimistic in its outlook and message.

[David · Rating 4 out of 5]

This is a famous paean to Open Source software, a bit dated now but still relevant. It explains very clearly why the OS movement is so popular; it also gives you an idea of why so many OS advocates are insufferable zealots. Eric Raymond is an ideologue preaching his message, and while he makes good points (usually), it does get very preachy at times (and also ignores some of the economic realities). Good reading if you're really into geek sociology and want to understand why Linux really was rather revolutionary.

[Geoff]

I'm intending to read this not because I have any knowledge of writing computer code or programming, and not because I have any particular interest in Linux except as a philosophy; however, picture a protagonist that is a HACKER, and the circumscribed and circuitous and serpentine paths that he followed through the strange years of the MILLENNIUM, and one might start to see something of an interesting story beginning to gather itself. Research for a possible PROJECT. How could a novel be shaped like THE INTERNET? Roubaud has conceived something similar in his ideal representation of The Great Fire of London series, written out in color-coded lines separate but connected by strands of text united by theme and time frame on immense circular walls. How would a book shaped like THE INTERNET feel in your hands? Or could it only exist on THE INTERNET? How would a paper book feel in your hands if it were to represent thousands of HYPERLINKS?

[Rohit Goswami · Rating 4 out of 5]

3.5 rounded up for historical reasons. I remember finishing this book some ten years ago. I was on a flight and I distinctly remember feeling like somehow this had changed my life... I vaguely recall blabbering on about it as I got my luggage with my dad.

It hasn't aged well. The core concepts have but, the culture has not. We've moved on from the hacker culture for the most part, tech bros aside, and that's a good thing. Good riddance. Have to admit the writing style was perfect for a fifteen year old me to be caught up in all the grandiose descriptions of tribes and honor and all that jazz. It's just a bunch of people hammering at keys. Nothing more. Nothing less. It is rather fun to read about all the old tech, and the changing attitudes towards the FSF (which continued in the right negative direction).

I guess, for what it's worth... It's a series of essays. The titular one is still a good read, but the cultural aspects are really very anachronistic.

[Odd Karsten Ropstad · Rating 4 out of 5]

The book is an exploration into the world of Open Source, and the culture that goes with it. It goes beyond the definitions and the initial perception and instead gives an inside view of a universe of hackers, magic cauldrons, bazaars and John Locke.

Open Source is nothing more than a development methodology, with its own sets of rules and principles. The difference from other methodologies is that the developers are not working in close approximation to each other. They are exclusively communicating through the internet. Though for some reason Open Source has become so much more. It is something more resembling a dogmatic approach to software development that by shear force of nature gathers engaged communities, tying them together tighter than most other communities, and included with them are their own social hierarchies formed based on recognition for produced work.

These communities are together creating a digital noosphere. Places where ideas and systems and ideas of systems, mingle and crash together to make free and open software. This cultural phenomenon is enabled by the developed connectedness that has come with the internet. In its early days in the 70s- with ARPANET, through the 80s and into the crazy 90s where Open Source became into its own as a great force for both disruption and innovation.

I think that open source will be more prevalent in the future, and this book is a great introduction into, the all too frequently used as a buzzword, Open Source. The book is interesting for anyone how is inclined to delve deeper into the world of Open Source, and it will give you a deeper perspective than usually comes when new technology is explained to the uninitiated.

[Erika RS]

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 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.

[Bastian Greshake Tzovaras · Rating 3 out of 5]

It's kind of funny to read, because there are so many cornerstones of techno-libertarian ideology presented in the essays. At the time the essays were written it was probably all kind of new and exciting, but nowadays those positions are kinda hard to defend.

The parts about Linus Torvalds are gold, as it's argued that he's such a sweet and agreeable person. And it's also pointed out how not attacking the authors and speaking softly are core skills when working in a Bazaar-like environment. I guess we all can safely call bullshit on those points, c.f. http://arstechnica.com/business/2015/...

All in all I'd say it's a good read if you want some historic context of the OSS movement, otherwise you can safely skip it.

[Zack · Rating 2 out of 5]

It was interesting to learn about the open-source software movement's history, business models, successes, and impact. Despite being informative, the essays feel more like a libertarian manifesto for software development than they do an open-source doctrine, and the author's self-importance is unbearable.

[Patrick Coakley · Rating 2 out of 5]

The Cathedral & The Bazaar is a set of essays that documents a specific period in time, the rise of Linux in the 90’s, with a bit of history to explain UNIX and the state of computers up until that point. It does a decent job of giving you an idea of what the open-source community was like at the beginning until roughly 1998. The author, Eric S. Raymond (also known as esr), has been involved in some way or another with open-source software since the movement began in the 80’s, and is also one of the only people who made it a point to document some of the major changes that were occurring in the industry at the time. The center-piece of this all is the titular essay, which is focused on the author’s experience of developing fetchmail, a Linux mail client, back in the early 90’s using an open development approach. You can read all the essays online for free if you just search the title, but I read the print version, which differs slightly due to added content and errata.

I think The Cathedral & The Bazaar could be a decent read, depending on the reader. To get the most impact out of it you would have to be someone who never really studied or read about the history of Linux, does not have a decent understanding of the open-source model, or just wants to learn more about some of the politics involved with open-source. I think these are really the book’s strong points.

Other than that, I don’t feel that the book holds up very well. The writing style feels very unfocused at times, with a lot of tangents or meandering that breaks up the flow. This is due to the anthropological theme that the author presents throughout the essays, trying to act as a guide to the reader for the culture and sociology of hackerdom. I think he fails in this regard because he tells the audience how things are instead of showing facts or evidence. There is a lack of hard figures to back up a lot of what he says, which weakens some of the points he tries to make when he throws out percentages, such as “one of the best-known folk theorems of software engineering is that 60% to 75% of conventional software projects either are never completed or are rejected by their intended users,” and “this is called “maintenance”, and any software engineer or systems analyst will tell you that it makes up the vast majority (more than 75%) of what programmers get paid to do.” I suppose we are supposed to take these statements at face value but I sure don’t.

There is also a strange need to always point out that “crackers” and “hackers” are not the same thing, and that people twisted the latter to mean the former. This is silly coming from an author that is trying to present hacker culture from an anthropological point of view – language and vocabulary change over time. Some of the things that are written authoritatively, such as Linus’ Law ("given enough eyeballs, all bugs are shallow"), are simply not true. If they were, we would have had things like Heartbleed or Dirty Cow. It feels like security as a topic was simply glossed over because it didn’t fit the narrative he was trying to tell.

I’m not quite sure why this book is always recommended as “required reading” for aspiring developers or people in the tech industry. There’s nothing here you can’t learn from searching around online. I think most of the insight would be common knowledge, and the historical value is kind of lost when you realize a lot of is needs to be taken with a grain of salt. It isn’t terribly long, and you can skip the parts you don’t like quite easily, however. I did get some enjoyment out of the first two essays, but everything after that was just not worth my time, and likely, not worth yours either.

[Richard Seltzer · Rating 5 out of 5]

I had read the title essay "The Cathedral and the Bazaar" on the Web about a year ago. In fact, I held a series of chats on the subject (which I considered to be "the Linux development model" So when the book came out, I presumed that I knew what it was all about. I just thought the author had expanded on that single brilliant idea and blown it up to book size. Little did I expect a book with such a broad scope and such far-reaching implications.

The title essay examines the question of how to make "open source" software projects work. In the background is the incredible success of Linux. In the foreground is the development of a mail utility with the author as the leader. Based on his experience, he tries to explain how it is possible to manage such a project -- with self-selected volunteers all over the world identifying and fixing bugs and contributing new code. The contrast is between software which is developed like a cathedral by a group working in isolation and only releasing the code when it is "totally finished"; vs. the open "great babbling bazaar" which is how open source development is described. He tries to understand what makes an effective manager in such an environment, and how to keep the volunteer team motivated and on target.

In the additional essays that appear in this book, Raymond takes a closer look at motivation, and comes to the conclusion that open source coders operate as in "gift economy" as opposed to an "exchange economy." The classic anthropological case of a gift economy was the Kwakuitl from the vicinity of what is now Vancouver. There social status was determined not by what you possessed but by what you could give away or deliberately sacrifice/destroy. This type of behavior/motivation is characteristic in cases of abundance -- whether for an entire society or a class within a society. The conspicuous consumption of Veblen's "leisure class" is an instance of this general phenomenon. It is easy to see it in operation in the exorbitant expenditures of Hollywood celebrities on parties and weddings, and the public charitable contributions of the wealthy. Raymond's application of this concept to the realm of open source coders is both unexpected and convincing.

He examines the behavior patterns of this set of people with the eye of an anthropologist, presuming that the truth lies in what they do rather than in the reasons they publicly state for their actions. He uncovers interesting contradictions between public statements and actual motivation, and makes a strong case for their close adherence to a rigid set of unwritten rules. As a key player in the very society that he is describing, he proudly takes on the very unanthropological role of helping these people better understand what makes them tick, as well as helping would-be leaders better understand how to lead in such an environment.

In other words, enabled by the Internet, a self-selecting group of people has evolved which operates with the motivations of a gift culture/economy. This culture crosses all geographic barriers and all social barriers, where membership has nothing to do with wealth or class in the traditional sense. Marx would have been dumbfounded.

As if that were not enough, Raymond goes on to make convincing arguments that two well-established "laws" of human behavior do not apply in this case.

According to Garrett Hardin's "tragedy of the commons," without law and supervision, a village of peasants will turn their common -- where all are free to graze their livestock -- into a mudhole. While they all might be aware that cooperation is necessary, without enforcement they each greedily try to grab as much as they can for their own livestock, which destroys the resource for all of them. Following such a model, one would expect that a team of software engineers could not stay together voluntarily for any extended period of time, that greed would lead to its inevitable and rapid collapse. But, as Raymond points out, "using software does not decrease its value. Indeed, widespread use of open-source software tends to increase its value, as users fold in their own fixes and features (code patches). In this inverse commons, the grass grows taller when it's grazed on." (p. 151)

Likewise, "Brook's Law" from the book The Mythical Man-Month by Fred Brooks, predicts that "as your number of programmers (N) rises, work performed scales as N but complexity and vulnerability to bugs rises as N squared, which tracks the number of communications paths (and potential code interfaces) between developers' code bases. Brooks's Law predicts that a project with thousands of contributors ought to be a flaky, unstable mess. Somehow the Linux community had beaten the N-squared effect and produced an operating system of astonishingly high quality." (p. 199)

Raymond's examination of what makes that possible leads to the inevitable conclusion that not only is open source development possible, but rather that it seems to be the only economically viable way to develop a large and important piece of software that will affect many people.

At the beginning of the book, it seemed like Linux was the anomaly -- a special case that might never reoccur. By the end, it appears that Microsoft is the anomaly -- that it is extremely difficult, extremely expensive, and almost impossible to build a program as immense as the Windows operating system without the help of a vast community of volunteers. With the Internet as an enabler, with Linux, Apache, and other projects as clear examples, and with Raymond's analysis of how it all works, open source seems to be the only logical way to go. The cathedral is not an alternative to the bazaar. Rather it is an historical artifact, an outmoded method of operation, left over from pre-Internet days.

Then with clear-headed balance, Raymond, rather than simply proclaiming victory, considers the limitations of open source, and when and how a balance of proprietary and open approaches is necessary.
All in all, this book helps open our eyes to an important new force that is changing the high-tech business world today. And at the s

[Stephen · Rating 4 out of 5]

The closest I've come to programming is HTML 4 and Excel, so a lot of this book was over my head. A someone who sorely missed the heady days of the 1990s when the Internet was a distinct place and some thought the beginning of a new world -- one free from control, allowing for limitless self-expression and an alternate society -- I found much else here fascinating. Particularly noteworthy were Raymond's connections between Linux-style open source development and the emergent order of free economies. While my own use of Linux distros is limited (I have Ubuntu and Mint boot disks for accessing the files of ailing Windows systems, but don't use them as daily drivers), its story is most interesting -- particularly given how many cellphones and servers run on Linux kernals these days.

[Rastko Vukasinovic · Rating 5 out of 5]

Being evergreen is really rare trait in any technology related text and it is exactly what The Cathedral and the Bazaar is.

It was never more relevant then it is today and it will be as relevant tomorrow.

[Alexander Smith · Rating 5 out of 5]

This book is a piece of history and an introduction to a culture that (if you're interested in real "hacker culture" and online culture) is not explained at its technological, economic, and social origins as well in any other text that I've seen. No more explanations are necessary. If you are interested in how born-web-native culture works, this is where you start.

[Dipti Ranjan Biswal · Rating 5 out of 5]

Must read for anyone who is even remotely related to software development or management.

[Ankush Chander · Rating 5 out of 5]

Book is witty and as it struck the right cords with the inner geek in me.

I like how author narrates the story of open source and how it was a paradigm shift in how collaboration happened, how things were built.

Also comparing it with closed software development.

Then there is underlying theme of being anti authoritarian, freedom loving citizen of the world.

I wish I had read it in college.

[Christina · Rating 4 out of 5]

Good, quick analysis of the strengths of open source software and how an open source project should be managed (at a very high level). Something worth reading for every software entrepreneur and developer, or at least worth skimming.

[Louis · Rating 4 out of 5]

How does a gift economy work? EricRaymond has a collection of essays written over the 1990's looking at the culture o software programming, in particular the subculture that develops and uses open source (or free software). In particular, his writings attempt to explain why does open source not fall into the trap of the free rider problem or the tragedy of the commons.

The answer he comes up with are several. One is the concept of 'scratch your own itch'. The idea that programmers find something that interests them, then solve it and open it to the world and other programmers do the same with the original code as a foundation. Another concept is 'none of us is as smart as all of us.' (my paraphrase) In this programmers who have to solve related problems join in and create a common solution (or a common base). Because each of them has expertise in his field, he has real contributions to make. However, each one of them has a real job, which is something other than writing web server programs (to use Apache as an example). Without open source, the contributions of these programmers would be lost, as they would expend their energies adapting other programs to meet their needs. With open source, the customer can become contributors to the project, and even small contributions can be captured.

Good writing. The focus is on understanding open source programming in a way that fits into the framework of economics and sociology. As EricRaymond is not a sociologist himself, he uses a mix of historical reflection, case studies where he was a major player, and observations on other projects from the outside. But the format is one of thinking about how you work, and how you work when building something as a team without the use of formal heirarchies.

[Mai · Rating 4 out of 5]

While a lot has changed since the book was first published, it still contains a lot of valuable information. Explains quite well why open source works and why people love to contribute.

[Neeraj · Rating 5 out of 5]

The author discusses the main points of difference between the two styles of software development i.e. the one employed by corporate organisations(microsoft and the likes) called as the cathedral by the author and the one adopted by the open source community (made popular by the success of linux kernel development) called as the bazaar by the author. He emphasizes on why the second model/approach leads to a much better software product even though it seems counter intuitive. All the points that are argued by traditional managers and organisation in favour of the cathedral style of development are addressed to by the author and pointed how they are covered or accounted for in the bazaar style of development. In the end he accepts that the success/end outcome of the software engineering product also depends on a lot of other factors as well than just the style of development used, he concludes that the one by bazaar style has a much greater chance of success. A must read for any software engineer.

[Jim Witschey · Rating 4 out of 5]

I've just started learning to use Unix systems and do some serious coding this year. This book is a really interesting look into the past 20 years or so of computing and how things came to be the way they are. ESR's writings collected here remind me just how crazy it is that Apache running on Linux is the most widely-used server setup on the web, that Perl and gcc are ubiquitous, and that the browser with the second-biggest market share is open-source. All in all, a very interesting and instructive read.

[Paul · Rating 4 out of 5]

A fascinating look at the history of open source software and an interesting attempt to analyse its origins and imperatives. The. book is a bit dated in places and, with the benefit of hindsight, some of the predictions are a bit optimistic, but a riveting read nonetheless.

[Paul Salmon · Rating 4 out of 5]

This book gives a very interesting insight into the state of Linux and Open Source in the late 1990s. From a historical perspective it shows the success of Linux and attributes this to using a far more flexible model than previous open source development. That is, Linus Torvalds style of development “release early and often, delegate everything you can, be open to the point of promiscuity” came as a surprise. This was a break from the “Cathedral Building” building process and more like a “a great babbling bazaar of differing agendas and approaches.” The author tried to understand how Linux with several thousand developers scattered over the globe did not fly apart in confusion. One of the premises is around the nature of software debugging - especially that “given enough eyeballs, all bugs are shallow”.

“Quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback from hundreds of users within days”

I recommend this book to those interested in software development and open source. It is an important book with significant insight that the industry at large still hasn’t digested in many aspects.

There are many other factors related to software development in this book that are still relevant today.

1. Gift cultures are adaptations not to scarcity but to abundance.

Open source is a gift culture and the author presents that the “reputation-game gift culture is the globally optimal way to cooperate for generating (and checking!) high quality creative work.”

Most economics is based on the principle of scarcity. (see also https://www.linkedin.com/pulse/all-so... )

Theresa Amabile’s 1984 study or motivation and reward is mentioned which observed “It may be that commissioned work will, in general, be less creative than work that is done out of pure interest.” She also observed that “the more complex the activity, the more it is hurt by extrinsic reward.” (Theresa Amabile almost 30 years later wrote The Progress Principle in 2011 which studied a number of teams over a long period and found that one of the best motivators was knowing that you are making progress. This book was also referenced by Dan Pink’s book drive.)

The last paragraph in the section “Gift outcompetes Exchange reads as follows:
“Indeed, it seems the prescription for highest software productivity is almost a Zen paradox; if you want the most efficient production, you must give up trying to make programmers produce. Handle their subsistence, give them their heads, and forget about deadlines. To a conventional manager this sounds crazily indulgent and doomed - but it is exactly the recipe with which the open source culture is now clobbering its competition”

I think that many hierarchical organisations are still struggling with the motivation and measurement of developer productivity and many progressive organisations are working to increase the autonomy of development teams with a view to greater productivity.


2. Software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.

The author uses the question “What is software worth when the producer is going out of business?” The answer is usually close to zero proving that the purchase of software is actually about trust that the producer will continue to enhance and support the software, thus a service relationship rather than a widget purchase relationship.

Red Hat from this time and based on the Open Source principles under which it abides sells only support and not software. Selling software for a fixed price and infinitely continuing support does not work. Use value rather than sale value is one alternative way to make money from software and is arguably the major driver of software development. That is, we don’t further develop software because we sold many copies, we develop because people are using it and asking for additional capability.

3. Usability
Usability was terrible in most software in the late 90s with attitudes like “Users are stupid” or “Users need more training”. The author knew that Open Source had a major hurdle which was that hackers were good at designing interfaces for other hackers but poor at modelling the thought processes of the other 95% of the population.

The author proposed that we need to “learn how to think about what we do in a fundamentally new way, and ruthlessly reducing the user visible complexity of the default environment to an absolute minimum. Computers are tools for human beings. Ultimately therefore, the challenges of designing hardware and software must come back to designing for human beings - all human beings."

We are still on this journey. Many modern software companies such as Spotify, Netflix, Uber, Facebook, Amazon, Xero, Trade Me are doing this well. Banks are catching up and government has seen some progress but still a lot of awful software processes.

[Matt Simmons · Rating 4 out of 5]

A twenty year old technology book that has held up surprisingly well. While Microsoft still dominates the desktop, Raymond's primary prediction--that open source models will come to dominate the "back end" and server-side parts of he internet--have come spectacularly true, because of the various reasons he spells out. While I'd be interested in seeing what the thinks of the state of things in the intervening years--with the rise of new tech giants Google, Facebook, Amazon, and a reborn Apple, social media, cloud computing, and mobile computing--and how these complicate his analysis, I get the feeling there's a lot in his thinking and analysis that still continues to make sense in our very different contexts.

The book is more than just an analysis of a particular software development model, though. While the title essay is about that model, and is referenced throughout the rest of the book, there are several other things at work here that make this a book of interest to non-technical audiences, especially those in management positions:

--An intriguing social and technical history of programming and the internet,
--An anthropological study of the culture of programmers and hackers, complete with an analysis of the ways in which prestige works in those cultures (this is the primary focus of "Homesteading the Noosphere," which should be required reading for non-technical managers of technical projects; if you're not a programmer but have programmers working under you, you need to read that essay)
--A reflection on the economics of software development. This is maybe the most suspect part of the book, but nevertheless provides some interesting reflections one can use to think through how best to monetize software and fold software development into a long-term business model, especially for a small or start-up business.

While not everyone will agree with Raymond's conclusions and not everyone will find every section interesting (the final essay and appendices can be skipped by someone not especially interested in Raymond's personal history or being a "hacker" oneself), twenty-ish years later there's still a lot here that is of real utility and interest.

In late 2017, this book is not a book for technical folks anymore (if it ever really was), but a collection of history, observations, and theorizing that proves to be exceptionally useful to anyone who's in a position of management/oversight to technical projects who may not be a "techie" him or herself.

[John Thompson · Rating 4 out of 5]

It seems that everybody who knows you read books wants to tell you about some book they have read and feel you will love. This usually annoys me because I like to choose my own books, however a much respected work colleague recommended that I should read, “The Cathedral and The Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary” by Eric S. Raymond. So I asked for this for my Birthday / Christmas, which are six days apart.

It is not just about technology, it is about a mindset around technology. In particular, it is about the open source development mindset.

Broadly speaking, there are two main ways to create software, which are either closed source or open source. Closed source usually entails a company creating a software program using in-house talent, where the source code for the program is kept locked up so as not to reveal the magic behind the program. Open source development on the other hand releases an original version of software into the wild and makes it possible for people around the world to contribute to and improve a piece of software.

In this book, closed source is described as a cathedral development model and open source as a bazaar development model. A cathedral is largely centrally planned, it takes a long time to create, it is not very open to change. If you build the Notre Dame Cathedral on the Île de la Cité in Paris, you are not going to pick it up and move it across the Seine if necessary.

Open source is described as the bazaar development model. The bazaar is lively and consists of a variety of buyers and sellers. If the bazaar is set up in an undesirable location, it can be moved to another side of the city in as little as a week. It is flexible and can quickly be adjusted to meet the needs of the buyers and sellers.

It was very interesting to read this book because it came out before the creation of Wikipedia and WordPress, along with a variety of other open source projects. This book has been called a manifesto for the open source movement, a “shot heard around the world” that got people thinking about development in a new way.

I recommend the book, even though it is 17 years old. Along with Hackers, it is one of those books that helps you see the path we have taken with technology.

I loved it.

[Mahmoud · Rating 5 out of 5]

I believe this is a revolutionary book for the software industry. It challenges the software development model, where a handful of engineers develope and maintain a software, according to the requirements of the management and customers.

The book gives two different metaphors for different software development models: cathedral and bazaar.

Cathedral is a software development model, where there is a fix engineer team that is responsible for the software. The product gets does not get released frequently and the team strives to make the product bug-free before releasing it. The software gets developed as if a cathedral is built. In a cathedral hierarchy rules and only restricted people are involved.

In contrast, bazaar is a software development model where no one will stop you from trading. In a bazaar model, you release the software quite frequently (maybe even once a day), and with enough co-developers all the bugs become shallow. This is exactly how Linux expanded as an open-source project.

The author argues that bazaar model wins the software development model competition by leaps and bounds, since there are many interested and talented people in the bazaar who seek joy in playing with interesting stuff. The comparison between GCC (GNU Compiler Collection) and EGCS (Experimental GNU Compiler System) is a clear evidence for this claim. GCC was being developed under cathedral model, whereas EGCS forked EGCS as an open source project, and only after some months EGCS became so better that FSF halted GCC and announced EGCS as its official GCC.

The author then raises a question: how to establish a bazaar? Start with a problem that is interesting for you. Write a piece of code that:
* runs
* the people should be convinced that it has the potential to improve

Nowadays the power of open-source is much more clear than when the author wrote the book. Linux continues to roar, Open Steam Map as the richest map and even asking the public about how to solve the biggest problems, e.g. extracting oil from a lake.

[Dillon Butvin · Rating 4 out of 5]

Hmm. How do I feel about this one. First off, it's a really unique and, at times, awesome book. Second, it is sometimes monotonous and drab for someone not familiar or nerded out on development. Third, it's fun and if you're a tech nerd you should definitely read it.

This book is a collection of essays, sometimes practical and sometimes philosophical. Truth be told, half of it was over my head and took some slowing down and rereading to grasp. I enjoy that from time to time but sometimes it was deep. REAL deep. And at times difficult. As such, also very rewarding upon grasping the concepts I wrestled with, such as staking claims in the internet and open source world (Homesteading the Noosphere).

The book explains the battles between open source and 'the man.' There are great arguments and logic for the open source argument... though I don't know if the logic always proves true. There have certainly been some great successes in open source and this book will give you a framework of why it works. It's also fun to get in the author's head of how he views his battle against the evil Microsoft, whether really true or very fluffed.

The back and forth and confusion of this review accurately portays how I feel at the end of this book. I also looked up a picture of the author and it is almost exactly who I pictured in my head. All said, really intriguing and impressive pieces of writing. Kudos, Eric.

[Catalin Gheorghe · Rating 5 out of 5]

A book that offers a glimpse into the history of hacker culture, unix and open-source world, with the main focus being the open-source development model. An easy and pleasurable read, containing impressive analogies with models from the economical and social domains.

Where necessary, the author provides references to studies and other works that go way beyond the technical domain of software development. To me, it was clear that the opinions exposed were properly researched and had a solid basis, and this is something I appreciate.

Even more than the thought provocative modelling of the open-source culture, what I enjoyed most about the work was the fact that it gave me an overview of a truly exciting period in computer science (beginning of time-sharing OS-es, Unix, GNU, open-source). It gave me a lot of opportunities to search for various other resources related to the people, institutions and technologies. All in all, reading the book made me feel that I could relate more strongly to today's "Linux and FOSS world", which I already am apart of, because I now better understand where it comes from and what where the initial events and values that led here. And it made me want even more to grasp the internals of Unix/Linux, different programming paradigms and proper software design.

[Matthew · Rating 3 out of 5]

I've seen this book cited a lot, so I figured I should read it. It is very interesting, though a bit longer and less coherent than I would like. The book is a collection of five separate but related essays about open source. I don't think the book has been updated in 20 years - there are numerous dead links including the author's website. And there are no case studies in this century. Considering the importance of this book to the history of open source, I'm surprised no one has taken it upon themselves to publish a second edition.

Sprinkled through the book are "rules" which represent the author's formalized knowledge of how software engineering culture works. 70% of the value of this book for me was in those rules, which amount to less than two pages of text. There are also some interesting anthropological musings here, if you're interested in that sort of thing. I found it especially interesting that he deduced rules of hacker motivation that people had been following but no one had written down before.

Check it out if you're interested in learning more about 20th century hacker culture. Just don't expect the links to work.

[Akhil Pundir · Rating 3 out of 5]

This is a great book to read for anyone who wants to know more about the origins of Open Source.
Not only did this book break my prejudice that there is no money in Open Source model but after reading this book i got to know of several business models which are thriving on Open source.
Linux was one of the main reasons i bought this book but it gave me an insight into the Hacker culture and the history of Hacker culture, where it really started and how it has evolved through the time.
There are several interesting analogies used in this book which kept me interested in reading more but some of the things were too technical for me, but it didn't matter because the point the author was trying to make was clear in the overall context.

But i would say that if you are looking for details of how to work with Open source then you should probably supplement this reading with something else, which goes into deeper details, but don't put off reading it because there is great value in lessons you can learn from this book.