There are several attempts to explain this situation. There are some effects unique to open source projects which seem to overcome the standard assumptions. One of the most notable can be summarized in the quote ``given enough eyeballs, all bugs are shallow'', attributed to Linus Torvalds. This implies that the debugging phase (where software errors are removed, either through code inspection or software testing) can be parallelized, given some coordination between the software coders. Of course, this can be done much more easily if source code is available (many more eyes can inspect it looking for bugs), and if the software is available to as many programmers as possible.
In any case, nowadays it is clear that open source development models are interesting case studies, where new methods for producing programs are being successfully tested. One of the first studies which highlighted some of the characteristics of these new development models was Eric Raymond's ``The Cathedral and the Bazaar'' [18]. In it, the author sheds some light on the problem of how successful open software software projects are managed. He analyzes two different categories of software development. One of them, which he calls ``cathedral-like development'' (as an analogy with how Middle Age cathedrals were built), is characterized by a relatively strong control on design and implementation. The other one, which he calls ``bazaar-like development'', is based on informal communication between the coders, and several small and medium coding efforts that can be chosen at will by the volunteers (as in a bazaar, where everyone can choose what he wants).
The cathedral-like is the traditional style of software management, although it is also used by some open source projects. In this model, there is a strong control on who can submit patches to the code, and how they are integrated, a clearly defined management structure, and a rigorous plan for code releases. On the other hand, the bazaar-like style uses a loose policy on code releases, and relatively informal control over who can provide patches for bugs or new functionality. The model can be characterized with a sentence: ``code often, release often''. This usually translates to a situation where long standing stable versions are available for general use, while the project follows on adding new features and fixing bugs in rapidly evolving development versions. While the former are released only from time to time, using higher quality assurance procedures, the latter are released with high frequency, so that programmers and users willing to test and improve those development versions can do it. Every time a new function is added, the code is released as a widely distributed development version. Sometimes this process is even extended to the code management system, so that anyone can get a current ``snapshot'' of what the programmers are working on at any given time.
Going into further detail, the bazaar-like model works in some sense as an accretion model, where a working application with a reasonable level of usefulness gets more and more functionality and patches, and in this way it gets incrementally better. Due to this incremental development, there is a window of time in the initial phases of development, when the software is still not functional enough to attract attention from other programmers, when some kind of funding would be very convenient (in terms of money, programmer time or other resources) to reach an initial point of usability. After this point is reached, the accretion process can start and show its power.
Both cases can be considered as extremes in a continuum of software development models. While open source software projects can use almost any model in that continuum, proprietary software projects can only with great difficulty try models different from the cathedral-like, and thus cannot benefit from the features of the bazaar-like ones.
It is, however, important to understand that open source software can be created with both approaches. In fact, there are cases like the gcc compiler and the XFree86 window system that are well known for following a model quite close to the cathedral-like. The important idea here is that open source software allowed for the first time for the introduction of successful alternative styles of software development. And many of these styles are well suited to several software projects where it is not possible to apply the rigidly defined rules of software production typical of cathedral-style development.