A terrific discussion of the psychology, mechanics, and economics of open source software. Also includes some nice chapters on hackers. Some bits are dated, but overall, the book largely holds up many years later.
The writing style is occasionally a little rigid or academic, but the content is great. Well worth a read for anyone interested in open source and the future of programming.
As usual, I've saved some of my favorite quotes from the book:
The idea of open source has been pursued, realized, and cherished over those thirty years by a vigorous tribe of partisans native to the Internet. These are the people who proudly call themselves "hackers"—not as the term is now abused by journalists to mean a computer criminal, but in its true and original sense of an enthusiast, an artist, a tinkerer, a problem solver, an expert.
The hacker culture and its successes pose by example some fundamental questions about human motivation, the organization of work, the future of professionalism, and the shape of the firm—and about how all of these things will change and evolve in the information-rich post-scarcity economies of the 21st century and beyond.
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).
"Given enough eyeballs, all bugs are shallow." I dub this: "Linus's Law".
Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect.
The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
Consider the way a puddle of water finds a drain, or better yet how ants find food: exploration essentially by diffusion, followed by exploitation mediated by a scalable communication mechanism.
In his [Gerald Weinberg's classic The Psychology of Computer Programming] discussion of "egoless programming", Weinberg observed that in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere.
Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.
The success of the open-source community sharpens this question considerably, by providing hard evidence that it is often cheaper and more effective to recruit self-selected volunteers from the Internet than it is to manage buildings full of people who would rather be doing something else.
Once again the example of the open-source community sharpens this question considerably—because we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.
It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work.
You do not become a hacker by calling yourself a hacker—you become a hacker when other hackers call you a hacker.
The verdict of history seems to be that free-market capitalism is the globally optimal way to cooperate for economic efficiency; perhaps, in a similar way, the reputation-game gift culture is the globally optimal way to cooperate for generating (and checking!) high-quality creative work.
There is a critical difference (Ryan observes) between saying, "I'm giving you this reward because I recognize the value of your work", and "You're getting this reward because you've lived up to my standards." The first does not demotivate; the second does.
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.
Open-source peer review is the only scalable method for achieving high reliability and quality.
Sometimes the smartest way to become a bigger frog is to make the pond grow faster. This, of course, is the economic reason technology firms have participated in public standards—and it's useful to think of open-source software as an executable standard.
The brutal truth is this: when your key business processes are executed by opaque blocks of bits that you can't even see inside (let alone modify) you have lost control of your business. You need your supplier more than your supplier needs you—and you will pay, and pay, and pay again for that power imbalance.
Specifically, hackerdom is what anthropologists call a gift culture. You gain status and reputation in it not by dominating other people, nor by being beautiful, nor by having things other people want, but rather by giving things away. Specifically, by giving away your time, your creativity, and the results of your skill.