Linus's law, named after Linus Torvalds, the creator of Linux, states that "given enough eyeballs, all bugs are shallow". More formally: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." The rule was formulated and named by Eric S. Raymond in his essay The Cathedral and the Bazaar.

Wikipedia can be viewed as an attempt to implement this principle in the realm of encyclopedia writing.

Linus Torvalds himself also describes a notion as Linus's Law in the prologue to the book The Hacker Ethic : Linus's Law says that all of our motivations fall into three basic categories. More important, progress is about going through those very same things as "phases" in a process of evolution, a matter of passing from one category to the next. The categories, in order, are "survival", "social life", and "entertainment". This idea is similar to that of Maslow's hierarchy of needs.

Criticism

Some studies have contested Linus's Law, citing the relatively small number of contributions made to open-source projects by "outside" people — that is, people not belonging to a small core group of developers [1]. This is largely the result of the necessary investment developers must make in setting up a build environment and understanding a piece of code before they can effectively contribute to it. Some projects also distrust external contributions, fearing that they might create difficult-to-find bugs or security holes, and so these projects create an inconvenient review process which can hinder external development.

These problems can be mitigated by effective software engineering practices, such as modular components with loose coupling, or a good test suite for verifying external contributions, or a simple deployment strategy supported by tools like autoconf. Another valuable aid is good documentation, including both high-level overviews and detailed interface descriptions, supported by tools such as Javadoc and code visualization tools. Although many open-source projects lack such discipline, many of the most successful projects achieved their success and developer base using these practices.

In security

One argument made against open source is that security flaws can be easily found by examining the source code, effectively destroying any security by obscurity. In reality, however, this is a good thing: it means that not only malicious users but also external developers and legitimate users can find such security holes more easily and diagnose attacks more quickly. By exposing problems sooner and to more people, security problems can often be fixed before the application is widely deployed and they become a more serious problem.

See also

• Peer review
• Adages named after people