ライナスの法則

ソフトウェア開発において、リーナスの法則とは「十分な数の目があれば、すべてのバグは浅くなる」という主張である。この法則はエリック・S・レイモンドがエッセイと著書『伽藍とバザール』 （1999年）で提唱し、リーナス・トーバルズに敬意を表して名付けられた。^{[1] [2]}

より正式な表現は、「ベータテスターと共同開発者の規模が十分に大きければ、ほぼすべての問題がすぐに特定され、修正方法も誰かに明らかになる」というものです。コードを複数の開発者に提示し、その受け入れについて合意を得ることは、ソフトウェアレビューの単純な形式です。研究者や実践者は、バグやセキュリティの問題を見つけるためのレビュープロセスの有効性を繰り返し実証してきました。^[3]

Robert Glass は著書「ソフトウェア工学に関する事実と誤謬」 の中で、この法則をオープンソース運動の「マントラ」と呼んでいますが、裏付けとなる証拠が不足していることと、追加のバグが発見される割合がレビュアーの数に比例しないことが研究で示されていることから、この法則は誤謬であるとしています。むしろ、有用なレビュアーの数は最大でも 2 人から 4 人程度であり、この数を超えるレビュアーがバグを発見する割合ははるかに低くなります。^[4]クローズドソースの実践者もソフトウェア プロジェクトの開発中に厳格で独立したコード分析を推進していますが、彼らは少数の人による詳細なレビューを重視しており、主に「目」の数を重視していません。^[5]

重要なコードに2年間存在したハートブリードのセキュリティバグは、レイモンドの格言の反証とみなされてきた。 ^{[6] [7] [8] [9]ラリー・セルツァーは、ソースコードが利用可能であるために、一部の開発者や研究者が}クローズドソースのソフトウェアよりも徹底的なテストを行わなくなり、バグが残りやすくなるのではないかと疑っている。^[9] 2015年、Linux Foundationのエグゼクティブディレクターであるジム・ゼムリンは、現代のソフトウェアの複雑さは、セキュリティを向上させるために特定のリソースを割り当てることが望ましいレベルにまで高まっていると主張した。2014年に世界で発生した最大のオープンソースソフトウェアの脆弱性のいくつかについて、彼は「これらのケースでは、目が実際には見ていなかった」と述べている。^[8]このマントラが実際にどの程度当てはまるかをテストするための大規模な実験や査読付き調査は行われていない。^[10]

^{Linus の法則[11]}の妥当性は、同じ組織内の人気のあるプロジェクトと人気のないプロジェクトを比較することで実証的に裏付けられました。人気のあるプロジェクトとは、GitHubスターの上位 5% (スター数 7,481 以上) のプロジェクトです。バグの特定は、バグ修正に関連していると判断されたコミットの割合である修正コミット確率を使用して測定されました。分析の結果、人気のあるプロジェクトではバグ修正の割合が高いことがわかりました (例: Google の人気プロジェクトでは、人気のないプロジェクトよりもバグ修正率が 27% 高かった)。Google が人気のあるプロジェクトでコード品質基準を下げた可能性は低いため、これは人気のあるプロジェクトでバグ検出の効率が向上したことを示しています。

• Jing Wang、JM Carroll (2011-05-27)。「Linus の法則の背後にあるもの: Mozi におけるオープンソース ソフトウェアのピア レビュー慣行の予備分析」。コラボレーション技術とシステムに関する国際会議 (CTS)、ペンシルベニア州フィラデルフィア。IEEE Xplore デジタル ライブラリ。pp. 117–124。doi : 10.1109 /CTS.2011.5928673。