The 80/20 Myth
One commonly cited statistics about open source software is that for any given project, 80% of the code is written by ~ 20% of the developers.
Although this statement is factually correct, its interpretations are often not. For example, some have used it to suggest that the development of open source software is not that different from the development of commercial software. Others have used it to justify the excluding community participation in the development process.
These interpretations assume that the value of software is directly proportional to lines of code, which is simply not true. Consider:
- The amount of time and effort required to get an 80% completed "alpha" release to a production release. How many of us have sat and waited for something that is "almost done"?
- The amount of time and effort required to gather the requirements and features in the beginning of a project. Look around your own company or at your vendors. How many people actually write code versus write use cases, gather requirements, manage projects, and perform QA?
- The biggest risk, and therefore one of the biggest costs, of software development is mis-specification. More software projects fail because of incorrect or inflexible specifications than any other reason.
This is where open source development processes can really reduce the costs and risks of software development. Open development processes are fundamentally collaborative. Developers and users work together to discuss what an application should do, how it should work, and how best to implement it. When a developer writes the code, others in the community help test it, report bugs, and even suggest fixes. These activities can be immensely valuable even if they result in relatively few lines of code.
Furthermore, over longer periods, the cost of maintaining software dwarfs the cost of producing the software. In open source communities, ongoing maintenance is spread over a large community of users and developers. Some will try novel uses or find new bugs. Others may think of new features and extend the application. Thus, the costs are not concentrated at any one particular user or developer organization.
The result: a better product with lower costs and less risk.