In 1975 aoftware engineer and computer scientist Frederick P. Brooks, Jr., founder and chair of computer science at the University of North Carolina at Chapel Hill, published The Mythical Man-Month: Essays on Software Engineering, a book on software engineering and project management. Brooks's book described what became known in software development as Brooks's Law: "adding manpower to a late software project makes it later".
"According to Brooks himself, the law is an 'outrageous oversimplification', but it captures the general rule. Brooks points to two main factors that explain why it works this way:
"1. It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of multiple engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even have negative contributions – for example, if they introduce bugs that move the project further from completion.
"2. Communication overheads increase as the number of people increase. The number of different communication channels increases along with the square of the number of people; doubling the number of people results in four times as many different conversations. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing."
"Compared with traditional software development, open source projects follow a different methodology. Large scale open source projects leverage the power of vast amount of participants which take care of coding and QA, using cheap communication channels (such as email) to coordinate the work. Such projects scale well, despite Brooks's Law, due to several reasons:
* Management concepts such as "manpower," "team size" and "delivery schedule" are not analogous in open source and internal corporate projects; applying Brooks's Law to both is thus misleading.
* Large scale open source projects have the ability to leverage the large number of testers to find bugs faster (also known as Linus's Law);
* Testers can read and analyze the source code, helping developers to track down bugs more efficiently;
* Efficient parallelization of work, reducing the communication overhead;
* A social context where the contributors are voluntary, associated with a leadership style that does not use coercion;
* Less reliance on traditional management methods to reduce duplication efforts.
* A more efficient allocation of labor to tasks . . .
"Some of these reasons, such as the parallelization of work could theoretically apply to both open source and closed projects" (Wikipedia article on Brooks's Law, accessed 08-08-2009).