Earlier quoted context omitted.
Tim Sort, Hamming Codes, Huffman Coding, RSA keys, LZW encoding, Duff's Device, Bloom Filter, Carmack's Reverse, awk, linux, git. We have a lot of things named after those that discovered, invented or popularized a structure or technique. Certainly nowhere near as commonly as does mathematics, I will agree. In CS, no doubt, we often end up on the other end, where a single term means different things in different cont…
Page rank. I thought git was named by Linus, and to the extent that it is named after him, it was self awareness of his reputation? I remember when Duff's Device was a neat trick; does anyone still use it these days? Edit: a neat trick, not a bear trick.
https://en.wikipedia.org/wiki/Linus%27s_law
>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. [...]
>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 as 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.
>Empirical support to the validity of Linus’s law [10] was obtained by comparing popular and unpopular projects of the same organisation. Organizations like Google and Facebook are known for their quality standards. Popular projects are projects with in the top 5% number of stars (7,481 stars or more). The bug identification was measured using the corrective commit probability, ratio of commits detected to fixing bug. The analysis showed that the popular projects had more bug fixing ratio (e.g., Google’s popular projects had 27% higher bug fix rate than Google’s less popular projects). Since it is unlikely that Google lowered its quality standard in it most popular projects, this is an indication of increased bug detection efficiency in popular projects.