Given Enough Eyeballs, all bugs are shallow and parallelizable

The complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly

The “severe effort of many converging wills” is precisely what a project like Linux requires—and the “principle of command” is effectively impossible to apply among volunteers in the anarchist’s paradise we call the Internet

Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this: “Linus’s Law”

The “utility function” Linux hackers are maximizing is not classically economic, but is the intangible of their own ego satisfaction and reputation among other hackers. (One may call their motivation “altruistic”, but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist)

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.

In fact, there have been open-source projects that maintained a coherent direction and an effective maintainer community over quite long periods of time without the kinds of incentive structures or institutional controls that conventional management finds essential

cases of successful recovery for software nonperformance are vanishingly rare. Even if they were common, feeling comforted by having somebody to sue would be missing the point. You didn’t want to be in a lawsuit; you wanted working software

once you have your people and machines and office space, you have to defend them from peer managers competing for the same resources, and from higher-ups trying to allocate the most efficient use of a limited pool.

in a world of cheap PCs and fast Internet links, we find pretty consistently that the only really limiting resource is skilled attention.

An equivalent and often-heard way to state my friend’s point is that traditional development management is a necessary compensation for poorly motivated programmers who would not otherwise turn out good work

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.

But Jamie was right to point out that going open will not necessarily save an existing project that suffers from ill-defined goals or spaghetti code or any of the software engineering’s other chronic ills. Mozilla has managed to provide an example simultaneously of how open source can succeed and how it could fail

Non–source-aware users tend to report only surface symptoms; they take their environment for granted, so they (a) omit critical background data, and (b) seldom include a reliable recipe for reproducing the bug.

Thus, source-code awareness by both parties greatly enhances both good communication and the synergy between what a beta-tester reports and what the core developer(s) know. In turn, this means that the core developers’ time tends to be well conserved, even with many collaborators.

The fundamental problem that traditional software-development organization addresses is Brook’s Law: “Adding more programmers to a late project makes it later.” More generally, Brooks’s Law predicts that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly.

the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only withinwithin that small core group do we pay the full Brooksian overhead.

9. Smart data structures and dumb code works a lot better than the other way around.

It’s fairly clear that one cannot code from the ground up in bazaar style [IN]. One can test, debug and improve in bazaar style, but it would be very hard to originateoriginate a project in bazaar mode. Linus didn’t try it. I didn’t either. 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 promiseplausible promise. Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future

fetchmail, that was run as a deliberate test of the surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the “cathedral” model of most of the commercial world versus the “bazaar” model of the Linux world.

By the time Linux swam onto my radar screen in early 1993, I had already been involved in Unix and open-source development for ten years. I was one of the first GNU contributors in the mid-1980s. I had released a good deal of open-source software onto the net, developing or co-developing several programs (nethack, Emacs’s VC and GUD modes, xlife, and others) that are still in wide use today. I thought I knew how it was done

I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required.

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

While I don’t claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it’s almost always easier to start from a good partial solution than from nothing at all.

5. When you lose interest in a program, your last duty to it is to hand it off to a competent successo

There have been other software products with a two-level architecture and a twotier user community that combined a cathedral-mode core and a bazaar-mode toolbox. One such is MATLAB, a commercial data-analysis and visualization tool. Users of MATLAB and other products with a similar structure invariably report that the action, the ferment, the innovation mostly takes place in the open part of the tool where a large and varied community can tinker with it

Linus seems to me to be a genius of engineering and implementation, with a sixth sense for avoiding bugs and development dead-ends and a true knack for finding the minimumeffort path from point A to point B. Indeed, the whole design of Linux breathes this quality and mirrors Linus’s essentially conservative and simplifying design approach.

Linus was keeping his hacker/users constantly stimulated and rewarded—stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even dailydaily) improvement in their work.