This is not a trivial question. According to most of what we think we know about software engineering, a software development effort as decentralized and unorganized as Linux ought to be a failure and a disaster. Linux should have collapsed years ago under the weight of insidious bugs and unanticipated interactions.
But Linux is not merely avoiding collapse, it is going from strength to strength at a speed no commercial operating system can match. Clearly, something about the model works. But up to now there has been remarkably little analysis of why, nor any attempt to discover which of the assumptions of classical software engineering have been falsified by the Linux experience.
In "The Cathedral And The Bazaar", I develop a software-engineering theory of Linux's success. I analyze Linus Torvalds's methods, extracting what I believe to be the behaviors key to growing an effective development community around Linux.
As confirmation, I present the results of an experiment I ran for six months in connection with the development of my "fetchmail" utility. I made a conscious effort to apply these key behaviors in the fetchmail project in order to see if I got results similar to Linus's (including not only the success of the software itself, but the rapid growth of an enthusiastic beta-tester and co-developer community).
The experiment was a resounding success. By six months after I began applying these methods, fetchmail had attracted a co-developer community of more than 200 people and come to completely dominate its niche in the free-software ecology.
I discuss the development of fetchmail in some detail in this paper; it offers many interesting lessons, especially when compared and contrasted with the history of Linux itself.
Classical software-engineering theory (as exemplified by Fred Brooks's "The Mythical Man Month") is dominated by pessimistic negative-scaling laws; "adding more programmers to a late project makes it later" and so forth. The lessons of Linux and the fetchmail development suggest to me that there is a positive scaling law which Linus Torvalds was the first person to learn to exploit systematically.
I develop "Linus's Law" by considering the contrast between a traditional "cathedral style" characteristic of commercial software development and the Free Software Foundation, and the "bazaar style" prototyped by the early Unix community and much intensified by Linus Torvalds. I discuss the characteristics of both styles. I argue that the successes of Linux and fetchmail demonstrate the superiority of the bazaar style (when objective conditions are such that it can be made to work at all).
I then argue that the fundamental difference between cathedral and bazaar styles is their opposed assumptions about the nature of the debugging task. The cathedral style is implied by the assumption that software bugs are deep, tricky, insidious phenomena that require the full-time attention of experts; the bazaar style is dependent on the assumption that bugs are shallow phenomena, readily found and fixed.
I then turn this logic around, proposing that the success of Linux and the bazaar style refutes the assumption of classical software engineering that development practice has to be controlled by a terror of intractable bugs. I counter-propose "Linus's Law": given a large enough beta-tester and co-developer base, all bugs are shallow.
I argue that "Linus's Law" (which Linus Torvalds endorses) is both a necessary and a sufficient condition for the success of Linux. I propose that it underlies all the significant features of the Linux development model, and that this model and Linus's kind of success *can be easily replicated* by almost any reasonably able hacker who understands how to apply it as I did.
Finally, I suggest some implications of this insight for the future of Linux, the free-software culture, and software in general.