Linus's law: Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
VisualWikitext
imported>OAbot
m Open access bot: url-access updated in citation with #oabot.
 
No edit summary
 
Line 9: Line 9:
In ''Facts and Fallacies about Software Engineering,'' [[Robert L. Glass|Robert Glass]] refers to the law as a "mantra" of the [[Open-source model|open source]] movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.<ref>{{cite book |last=Glass |first=Robert L. |title=Facts and Fallacies of Software Engineering |isbn=0-321-11742-5 |year=2003 |publisher=[[Addison-Wesley]] |page=174 |url=https://books.google.com/books?id=3Ntz-UJzZN0C&pg=PA174}} {{ISBN|978-0321117427}}.</ref> While closed-source practitioners also promote stringent, independent [[code analysis]] during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".<ref>{{cite book|last1=Howard |first1=Michael |last2=LeBlanc |first2=David |title=Writing Secure Code, 2nd. Ed. |pages=44–45, 615, 726 |isbn=0-7356-1722-8 |publisher=[[Microsoft Press]] |year=2003 |url=https://books.google.com/books?id=Uafp7m2wPcMC&q=Writing+Secure+Code }}</ref>
In ''Facts and Fallacies about Software Engineering,'' [[Robert L. Glass|Robert Glass]] refers to the law as a "mantra" of the [[Open-source model|open source]] movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.<ref>{{cite book |last=Glass |first=Robert L. |title=Facts and Fallacies of Software Engineering |isbn=0-321-11742-5 |year=2003 |publisher=[[Addison-Wesley]] |page=174 |url=https://books.google.com/books?id=3Ntz-UJzZN0C&pg=PA174}} {{ISBN|978-0321117427}}.</ref> While closed-source practitioners also promote stringent, independent [[code analysis]] during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".<ref>{{cite book|last1=Howard |first1=Michael |last2=LeBlanc |first2=David |title=Writing Secure Code, 2nd. Ed. |pages=44–45, 615, 726 |isbn=0-7356-1722-8 |publisher=[[Microsoft Press]] |year=2003 |url=https://books.google.com/books?id=Uafp7m2wPcMC&q=Writing+Secure+Code }}</ref>


The persistence of the [[Heartbleed]] security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum.<ref>{{cite web |first=Bruce |last=Byfield |title=Does Heartbleed Disprove 'Open Source is Safer'? |work=[[Datamation]] |date=April 14, 2014 |url=https://www.datamation.com/open-source/does-heartbleed-disprove-open-source-is-safer-1.html }}</ref><ref>{{cite journal |doi=10.1038/scientificamerican0714-14 |first1=Edward W. |last1=Felten |first2=Joshua A. |last2=Kroll |title=Help Wanted on Internet Security |journal=Scientific American |year=2014 |volume=311 |issue=1 |page=14 |pmid=24974688 |bibcode=2014SciAm.311a..14F }}</ref><ref name="Bugs Aren't Shallow" /><ref name="Heartbleed matter" /> Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with [[closed source]] software, making it easier for bugs to remain.<ref name="Heartbleed matter">{{Cite web|url=https://www.zdnet.com/article/did-open-source-matter-for-heartbleed/ |date=April 14, 2014 |title=Did open source matter for Heartbleed?|first=Larry|last=Seltzer|website=ZDNet}}</ref>
The persistence of the [[Heartbleed]] security bug in a critical piece of code for two years has been considered a refutation of Raymond's dictum.<ref>{{cite web |first=Bruce |last=Byfield |title=Does Heartbleed Disprove 'Open Source is Safer'? |work=[[Datamation]] |date=April 14, 2014 |url=https://www.datamation.com/open-source/does-heartbleed-disprove-open-source-is-safer-1.html }}</ref><ref>{{cite journal |doi=10.1038/scientificamerican0714-14 |first1=Edward W. |last1=Felten |first2=Joshua A. |last2=Kroll |title=Help Wanted on Internet Security |journal=Scientific American |year=2014 |volume=311 |issue=1 |page=14 |pmid=24974688 |bibcode=2014SciAm.311a..14F }}</ref><ref name="Bugs Aren't Shallow" /><ref name="Heartbleed matter" /> Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with [[closed source]] software, making it easier for bugs to remain.<ref name="Heartbleed matter">{{Cite web|url=https://www.zdnet.com/article/did-open-source-matter-for-heartbleed/ |date=April 14, 2014 |title=Did open source matter for Heartbleed?|first=Larry|last=Seltzer|website=ZDNet}}</ref>
In 2015, the [[Linux Foundation]]'s executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source [[software vulnerabilities]], he says, "In these cases, the eyeballs weren't really looking".<ref name="Bugs Aren't Shallow">{{cite web | title=Why All Linux (Security) Bugs Aren't Shallow | date=February 20, 2015 | first=Sean Michael | last=Kerner | publisher=eSecurity Planet | url=http://www.esecurityplanet.com/open-source-security/why-all-linux-security-bugs-arent-shallow.html | access-date=February 21, 2015}}</ref> Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.<ref>{{Cite journal |last=Arceneaux |first=Kevin |last2=Gerber |first2=Alan S. |last3=Green |first3=Donald P. |date=January 2006 |title=Comparing Experimental and Matching Methods Using a Large-Scale Voter Mobilization Experiment |url=https://www.cambridge.org/core/journals/political-analysis/article/abs/comparing-experimental-and-matching-methods-using-a-largescale-voter-mobilization-experiment/E7B43806BEE0FB3000EE6627A9C03720 |journal=Political Analysis |language=en |volume=14 |issue=1 |pages=37–62 |doi=10.1093/pan/mpj001 |issn=1047-1987|url-access=subscription }}</ref>
In 2015, the [[Linux Foundation]]'s executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source [[software vulnerabilities]], he says, "In these cases, the eyeballs weren't really looking".<ref name="Bugs Aren't Shallow">{{cite web | title=Why All Linux (Security) Bugs Aren't Shallow | date=February 20, 2015 | first=Sean Michael | last=Kerner | publisher=eSecurity Planet | url=http://www.esecurityplanet.com/open-source-security/why-all-linux-security-bugs-arent-shallow.html | access-date=February 21, 2015}}</ref> Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.<ref>{{Cite journal |last=Arceneaux |first=Kevin |last2=Gerber |first2=Alan S. |last3=Green |first3=Donald P. |date=January 2006 |title=Comparing Experimental and Matching Methods Using a Large-Scale Voter Mobilization Experiment |url=https://www.cambridge.org/core/journals/political-analysis/article/abs/comparing-experimental-and-matching-methods-using-a-largescale-voter-mobilization-experiment/E7B43806BEE0FB3000EE6627A9C03720 |journal=Political Analysis |language=en |volume=14 |issue=1 |pages=37–62 |doi=10.1093/pan/mpj001 |issn=1047-1987|url-access=subscription }}</ref>


Latest revision as of 20:10, 9 August 2025

Template:Short description

In software development, Linus's law is the assertion that "given enough eyeballs, all bugs are shallow". The law was formulated by Eric S. Raymond in his essay and book The Cathedral and the Bazaar (1999), and was named in honor of Linus Torvalds.[1][2]

A more formal statement is: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." Presenting the code to multiple developers with the purpose of reaching consensus about its acceptance is a simple form of software reviewing. Researchers and practitioners have repeatedly shown the effectiveness of reviewing processes in finding bugs and security issues.[3]

Validity

In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5]

The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered a refutation of Raymond's dictum.[6][7][8][9] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[9] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[8] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.[10]

Empirical support of the validity of Linus's law[11] was obtained by comparing popular and unpopular projects of the same organization. Popular projects are projects with the top 5% of GitHub stars (7,481 stars or more). Bug identification was measured using the corrective commit probability, the ratio of commits determined to be related to fixing bugs. The analysis showed that popular projects had a higher ratio of bug fixes (e.g., Google's popular projects had a 27% higher bug fix rate than Google's less popular projects). Since it is unlikely that Google lowered its code quality standards in more popular projects, this is an indication of increased bug detection efficiency in popular projects.

See also

Script error: No such module "Portal". Template:Div col

Template:Div col end

References

Template:Reflist

Further reading

  • Script error: No such module "citation/CS1".

Script error: No such module "Navbox". Template:Computer laws

  1. ↑ Script error: No such module "citation/CS1".
  2. ↑ Script error: No such module "citation/CS1".
  3. ↑ Script error: No such module "citation/CS1".
  4. ↑ Script error: No such module "citation/CS1". Template:ISBN.
  5. ↑ Script error: No such module "citation/CS1".
  6. ↑ Script error: No such module "citation/CS1".
  7. ↑ Script error: No such module "Citation/CS1".
  8. ↑ a b Script error: No such module "citation/CS1".
  9. ↑ a b Script error: No such module "citation/CS1".
  10. ↑ Script error: No such module "Citation/CS1".
  11. ↑ Script error: No such module "citation/CS1".
Retrieved from "http://debianws.lexgopc.com/wiki143/index.php?title=Linus%27s_law&oldid=3219876"