Eric S. Raymond

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å.… (lisätietoja)

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 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.… (lisätietoja)