Indeholder "Foreword", "Preface: Why You Should Care", "A Brief History of Hackerdom", " Prologue: The Real Programmers", " The Early Hackers", " The End of Elder Days", " The Proprietary-Unix Era", " The Early Free Unixes", " The Great Web Explosion", "The Cathedral and the Bazaar", " The Cathedral and the Bazaar", " The Mail Must Get Through", " 1. Every good work of software starts by scratching a developer's personal itch", " 2. Good programmers know what to write. Great ones know what to rewrite (and reuse)", " 3. 'Plan to throw one away; you will, anyhow" (Fred Brooks, The Mythical Man-Month, Chapter 11)", " 4. If you have the rigth attitude, interesting problems will find you", " 5. When you lose interest in a program, your last duty is to hand it off to a competent successor", " The Importance of Having Users", " 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging", " Release Early, Release Often", " 7. Release Early. Release Often. And listen to your customers", " 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone", " Many Eyeballs Tame Complexity", " When Is a Rose Not a Rose?", " 9. Smart data structures and dumb code works a lot better than the other way around", " 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource", " Popclient Becomes Fetchmail", " 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better", " 12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong", " 13. 'Perfection [in design] is achieved not whten there is nothing more to add, but rather when there is nothing more to take away.'", " Fetchmail Grows Up", " 14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected", " 15. When writing gateway software of any king, take pains to disturb the data stream as little as possible - and never throw away information unless the recipient forces you to!", " A Few More Lessons from Fetchmail", " 16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend", " 17. A security system is only as secure a its secret. Beware of pseudo-secrets", " Necessary Preconditions for the Bazaar Style", " The Social Context of Open-Source Software", " 18. To solve an interesting problem, start by finding a problem that is interesting to you", " 19. Provided the development coordinator has a communications medium at least as good as the internet, and knows how to lear without coercion, many heads are inevitably better than one", " On Management and the Maginot Line", " Epilog: Netscape Embraces the Bazaar", "Homesteading the Noosphere", " An Introductory Contradiction", " The Varieties of Hacker Ideology", " Promiscuous Theory, Puritan Practice", " Ownership and Open Source", " Locke and Land Title", " The Hacker Milieu as Gift Culture", " The Joy of Hacking", " The Many Faces of Reputation", " Ownership Rights and Reputation Incentives", " The Problem of Ego", " The Value of Humility", " Global Implications of the Reputation-Game Model", " How Fine a Gift?", " 1. If it doesn't work as well as I have been led to expect it will, it's no good - no matter how clever and original it is", " 2. Work that extends the Noosphere is better than work that duplicates an existing piece of functional territory", " 3. Work that makes it into a major distribution is better than work that doesn't. Work carried in all major distributions is most prestigious", " 4. Utilization is the sincerest form of flattery and category killers are better than also-rans", " 5. Continued devotion to hard, boring work (like debugging, or writing documentation) is more praiseworthy than cherrypicking the fun and easy hacks", " 6. Nontrivial extensions of function are better than low-level patches and debugging", " Noospheric Property and the Ethology of Territory", " Causes of Conflict", " Project Structures and Ownership", " Conflict and Conflict Resolution", " Acculturation Mechanisms and the Link to Academia", " Gift Outcompetes Exchange", " Conclusion: From Custom to Customary Law", " Questions for Further Research", "The Magic Cauldron", " Indistinguishable from Magic", " Beyond Geeks Bearing Gifts", " The Manufacturing Delusion", " The 'Information Wants to Be Free' Myth", " The Inverse Commons", " Reasons for Closing Source", " Use-Value Funding Models", " The Apache Case: Cost-Sharing", " The Cisco Case: Risk-Spreading", " Why Sale Value Is Problematic", " Indirect Sale-Value Models", " Loss-Leader/Market Positioner", " Widget Frosting", " Give Away the Recipe, Open a Restaurant", " Accessorizing", " Free the Future, Sell the Present", " Free the Software, Sell the Brand", " Free the Software, Sell the Content", " When to Be Open, When to Be Closed", " What Are the Payoffs?", " How Do They Interact?", " Doom: A Case Study", " Knowing When to Let Go", " Open Source as a Strategic Weapon", " Cost-Sharing as a Competive Weapon", " Resetting the Competition", " Growing the Pond", " Preventing a Chokehold", " Open Source and Strategic Business Risk", " The Business Ecology of Open Source", " Coping with Success", " Open R&D and the Reinvention of Patronage", " Getting There from Here", " Conclusion: Life After the Revolution", " Afterword: Why Closing a Drivers Loses Its Vendor Money", "Revenge of the Hackers", " Revenge of the Hackers", " Beyond Brooks's Law", " Memes and Mythmaking", " The Road to Mountain View", " The Origins of 'Open Source'", " 1. Forget Bottom-Up; Work on Top-Down", " 2. Linux Is Our Best Demonstration Case", " 3. Capture the Fortune 500", " 4. Co-opt the Prestige Media that Serve the Fortune 500", " 5. Educate Hackers in Guerrilla Marketing Tactics", " 6. Use the Open Source Certification Mark to Keep Things Pure", " The Accidental Revolutionary", " Phases of the Campaign", " The Facts on the Ground", " Into the Future", "Afterword: Beyond Software?", "Appendix A: How to Become a Hacker", " Why This Document?", " What Is a Hacker?", " The Hacker Attitude", " 1. The World Is Full of Facinating Problems Waiting to Be Solved", " 2. Nobody Should Ever Have to Solve a Problem Twice", " 3. Boredom and Drudgery Are Evil", " 4. Freedom Is Good", " 5. Attitude Is No Substitute for Competence", " Basic Hacking Skills", " 1. Learn How to Program", " 2. Get One of the Open-Source Unixes and Learn to Use and Run It", " 3. Learn How to Use the World Wide Web and Write HTML", " Status in the Hacker Culture", " 1. Write Open-Source Software", " 2. Help Test and Debug Open-Source Software", " 3. Publish Useful Information", " 4. Help Keep the Infrastructure Working", " 5. Serve the Hacker Culture Itself", " The Hacker/Nerd Connection", " Points for Style", " Other Resources", " Frequently Asked Questions", "Appendix B: Statistical Trends in the Fetchmail Project's Growth", "Notes, Bibliography and Acknowledgments", " A Brief History of Hackerdom", " The Cathedral and the Bazaar", " Homesteading the Noosphere", " The Magic Cauldron", " For Further Reading", "Index".

Interessant beretning om softwareudvikling. Der er ikke rigtigt nogen sikker strategi på at erobre verden, se fx afsnittet om Mozilla. Den er pudsig at læse her 20 år efter, hvor folk har accepteret at windows og office 365 er noget man abonnerer på. ( )

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.

Raymond's methodical approach to describing the benefits of open source programming as well as the scenarios under which it flourishes and why is very clear. A good read for all geeks. ( )

I enjoyed reading this more then I expected at first, given its age. The initial essay was really good and the highlight of the book. The essay in the middle was a little to academically analytical for casual reading, but would be quite interesting if doing research on the open source community. The last essay was a nice general narrative of Eric Raymond's experience since writing the initial essay. ( )

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