The Law was established by Eric S. Raymond in his book The Cathedral and The Bazaar. The law is named after Linus Torvalds.
Raymond stated that, “Given a large enough beta tester and co-developer base, almost every problem will be characterized quickly and the fix is obvious to someone.” In simpler words, “given enough eyeballs, all bugs are shallow.”
You must be wondering how this is relevant to a software. The answer is that an operating system or application will be more secure when you can inspect the code, share it with experts and other members of your user community, identify potential problems and create fixes quickly. Implying that, the security benefits of open source software depend directly from its openness and quality assurance. An operating system or application will be more credible if a qualified person inspects the code, identifies potential problems and fixes it in minimum time.
Linus aimed at maximizing the number of person-hours thrown at debugging and development, even at the potential cost of instability in the code and user-base burnout if any serious bug proved intractable. He formulated that given a large enough beta-tester and co-developer base, almost every problem can be characterized and fixed quickly.
A dichotomy between the cathedral-builder and bazaar styles lies within the Linus Law. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes a decent amount of time for a dedicated few to develop confidence that’s desired.
Whereas, in the bazaar view, it is assumed that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release.
Open Source Software:
Linus’s law highlights the power of open source software (OSS) preview. As a high-profile model of large-scale online collaboration,OSS development often involves globally dispersed experts, mostly volunteers, collaborating over the Internet to produce software with source code freely available. Peer review is one of the core collaborative practices of OSS development: distributed participants evaluate and test the released software products, and report any problems they discovered or experienced; others jointly analyze and identify software defects or deficiencies, and generate solutions for repairing or improving the software products. Participants who contribute to bug reports are crucial assets for OSS projects to retain. This is because they are certainly more motivated than general Firefox users as they use more efficient bug tracking systems to report, analyze and fix bugs.
OSS peer review is widely believed to be remarkably benefiting from a large community, “many eyeballs” of members with different perspectives. In general, the OSS preview process begins with one submitting a bug report to the bug tracking system—an application that helps developers keep track of reported defects or deficiencies of source code, design, and documents. Others examine the defect causes and request additional information to determine whether the bug should be fixed. Once a solution is reached, they then commit a change set (mostly a patch) to the current software product.
The law is often referred to as a “mantra” of the Open source movement, but also a fallacy owing to the lack of supporting evidence. Furthermore, several researches have indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers. Practitioners also promote rigid, separate code analysis during a software project’s development. They tend to focus on in-depth review by a few and not primarily the number of “eyeballs.”
