The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary from Eric Raymond is the Bible on Open Source development. I read two other books on Open Source over the last few months and can’t believe I let this book sit on my shelf while I read the others. This is the first book that should be read on Open Source.
Eric Raymond has been writing open source software since the 70’s and is a principle figure in shaping and chronicling the Open Source Movement. You can see him in Revolution OS (on Netflix Instant View), a well-produced and interesting documentary on the history of open source. 4 out of 5 [NordicTrack] Ski Stars (not the highest rating only because he bashed Microsoft so much. 🙂
p.16 The most important feature of Linux was not technical but sociological. Until the Linux development, everyone believed that any software as complex as an operating system had to be developed in a carefully coordinated way by a relatively small tightly knit group of people.
p.21 Linus Torvalds’s style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet reverent cathedral building here. Rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches.
p.23 Every good work of software starts by scratching a developer’s personal itch. Good programmers know what to write. Great ones know what to rewrite and reuse. They know you get an A not for effort, but for results, and it’s almost always easier to start from a good partial solution than from nothing at all.
p.25 You often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right.
p.27 Treating your users as co-developers is your least hassle route to rapid code improvement and effective debugging.
I think Linus’s cleverest and most consequential act was not the construction of the Linux kernel itself, but rather his invention of the Linux development model.
p.29 Release early, release often, and listen to your customers.
p.30 Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
p.38 If you treat your beta testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
p.40 The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
p.47 Your nascent developer community needs to have something runnable and testable to play with. When you start community-building, what you need to be able to present is a plausible promise. What your program must do is 1) run and 2) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.
p.59 Customers are going to know that the problem was solved by someone who chose that problem to solve because of a fascination with the problem itself, which in software as in other kinds of creative work, is a far more effective motivator than money alone.
p.161 In a swiftly changing world and a rapidly complexifying and information-centered economy, there will always be plenty of work and a healthy demand for people who can make computers do things, no matter how much time and how many secrets they give away.