"Early and frequent releases are a critical part of the Linux development model. Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don't want to wear out the patience of your users."

"Linus's open development policy was the very opposite of cathedral-building."

"Linux's Internet archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases."

"Linus was treating his users as co-developers in the most effective possible way:"

"Release early. Release often. And listen to your customers."

"Linus's innovation wasn't so much in doing quick-turnaround releases incorporating lots of user feedback (something like this had been Unix-world tradition for a long time), but in scaling it up to a level of intensity that matched the complexity of what he was developing."

"Because he cultivated his base of co-developers and leveraged the Internet for collaboration harder than anyone else, this worked."

"Put that way, the question answers itself. 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 daily) improvement in their work."

"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."

"``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''."

"Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it."

"And I'll go on record as saying that finding it is the bigger challenge.''"

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

"It appears that what Linus has shown is that this applies even to debugging an operating system—that the Delphi effect can tame development complexity even at the complexity level of an OS kernel. [CV]"

"One special feature of the Linux situation that clearly helps along the Delphi effect is the fact that the contributors for any given project are self-selected."

"In practice, the theoretical loss of efficiency due to duplication of work by debuggers almost never seems to be an issue in the Linux world. One effect of a ``release early and often'' policy is to minimize such duplication by propagating fed-back fixes quickly"

"The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly this cost is strongly affected by the number of users. More users find more bugs."

"More users find more bugs because adding more users adds more different ways of stressing the program."

"So adding more beta-testers may not reduce the complexity of the current ``deepest'' bug from the developer's point of view, but it increases the probability that someone's toolkit will be matched to the problem in such a way that the bug is shallow to that person."