Category: 法則
Type: オープンソース協働とソフトウェア品質のヒューリスティクス
Origin: Eric S. Raymond、『伽藍とバザール』（First Monday、1998；O’Reilly 書籍、1999）；Linus Torvalds にちなんで命名
Also known as: 「十分な目があれば、すべてのバグは浅い」
Type: オープンソース協働とソフトウェア品質のヒューリスティクス
Origin: Eric S. Raymond、『伽藍とバザール』（First Monday、1998；O’Reilly 書籍、1999）；Linus Torvalds にちなんで命名
Also known as: 「十分な目があれば、すべてのバグは浅い」
先に答えると — リーナスの法則（Linus’s Law）は、十分なテスターと共同開発者がいれば、ほぼすべての問題は素早く特徴づけられ、誰かには修正が自明になる、という主張です。目が増えても能力は自動では生まれません。「誰かが正しい視点を持つ」確率が上がるだけです。レビューとリリースのループ設計に使い——人気コードが安全だという保証にはしないでください。
リーナスの法則とは
リーナスの法則は、広く多様な精査が、閉じた大聖堂型開発に比べて欠陥を浅くする——見つけやすく、直しやすくする——というソフトウェア工学上の主張です。十分な目があれば、すべてのバグは浅い。Eric S. Raymond のより正式な言い方はこうです。十分なベータテスターと共同開発者基盤があれば、ほぼすべての問題は素早く特徴づけられ、誰かには修正が自明になる。公園で落とした鍵を想像してください。一人の歩行者は何日も見逃すかもしれません。同じ道を百人が横切れば、早く見つかる確率は上がります。コードにおける「浅い」は永遠に些細だという意味ではなく——十分な注意深い頭脳に晒されれば、特徴づけと修復が加速する、という意味です。
リーナスの法則を3つの深さで理解する
- Beginner: 多くの慎重な読み手が、小さな閉じたチームより速くバグを見つける。
- Practitioner: フィードバックのために早めに出すが、レビューアーが実際に実行・読解・報告できる場合に限る。
- Advanced: インセンティブ・ツール・専門性がリスク面を覆うとき目は役立つ。その覆いがないと、人気だけでは深いバグが残る。
起源
Eric S. Raymond は『伽藍とバザール』で Linus’s Law という名を付けました。文章は 1998年3月に First Monday で広く発表され、のちに O’Reilly 書籍（1999）へ拡張されました。名前は Linus Torvalds に由来します。早期・頻繁リリースと外部貢献への開放という Linux の開発様式が、小さな孤立チームが築く「大聖堂」プロジェクトと対比されるからです。 Raymond は、大聖堂型はバグを深く陰湿な現象とみなし稀にしか出荷しない一方、バザール型は多くの共同開発者が各リリースを叩けばバグは概ね浅くなる、と論じました。Torvalds はのちに Raymond が取り入れた重要な区別を明確にしました。バグを見つける人と理解して直す人はしばしば別人であり——見つける方が難しいことが多い、と。したがってこの法則は、並列的な検索に依拠し、報告者全員がデバッグ名人である必要はありません。要点
リーナスの法則は、検索と視点の多様性への賭けであり、リポジトリにスターを付ける魔法ではありません。発見と修正を分ける
発見と修正は別の仕事です。コミュニティ報告は症状を表面化できますが、根本原因のパッチにはメンテナの専門性が要ります——人が増えると協調コストで遅くなる、というブルックスの法則とは別の話です。
名声よりカバレッジ
広く使われるコードでも、ほとんど踏まれない経路は隠れます。コミュニティレビューにテスト・ファジング・焦点監査を組み合わせてください——インセンティブが弱いところほど。ハイラムの法則も、沈黙の依存が壊れた縁を隠すと警告します。
応用場面
作業を本当に見て負荷をかけられる人を広げられるとき、リーナスの法則を使います。オープンソースの保守
変更履歴を公開し、再現可能なバグレポートを招き、セキュリティ問題は暗号とメモリ安全を見られる人へ回します——機能ファンだけではありません。
社内コードレビュー
レビューアーをチーム横断で回し、実行可能なデモを求め、「動かさずに LGTM」を失敗した目として扱います。
製品ベータ
本番で壊れる表面を覆うよう、実エッジケース（ロケール、端末、アクセシビリティ）に合う利用者を集めます。
学習と執筆
反対意見を持つ仲間に草稿を早めに共有します。カニンガムの法則は近縁で——誤った・不完全な主張は、私的な磨き上げより速く訂正を招きがちです。
事例
Heartbleed は、「十分な目」が自動ではないことを示します。OpenSSL の TLS Heartbeat 欠陥（CVE-2014-0160）は 2011年12月31日にソースツリーへ導入され、OpenSSL 1.0.1 として 2012年3月14日に広く出荷され、修正版 1.0.1g とともに 2014年4月7日に公開開示されました——公共ウェブの多くを支えるライブラリで、2年以上の露出です。欠落した境界チェックにより、攻撃者はリクエストごとに約 64 KB のプロセスメモリを読め、鍵や資格情報を取り得る状態でした。 OpenSSL はオープンソースで重度に使われていました。それでも一般トラフィックでは気づかれず、専門家による発見（Google Security や Codenomicon に関連する報告を含む）が協調開示を強いるまで残りました。教訓は、開かれたレビューが無価値だということではなく、リーナスの法則には踏まれたコード経路への関連する目と、沈黙のメモリバグを探す動機が要る、ということです。境界も重要です。開示後、同じオープンな生態系は迅速にパッチを出しました。失敗は、特徴づけ後の応答不能ではなく、長く検知されなかった深さにありました。限界と失敗パターン
「多くの利用者」が「多くのレビューアー」でないとき、リーナスの法則は失敗します。ダウンロードは監査ではありません。暗号・並行・ハードウェア固有の欠陥は、カジュアルな貢献者が欠く希少な専門性と道具を要します。 報告を抑える社会力学でも失敗します。敵意あるメンテナ文化、不明瞭な貢献経路、責任への恐れは、実効の目の数を縮めます。 よくある誤用は、オープンソースが閉ソースより自動的に安全だと主張することです。開放は精査の機会であり、正しさの証明書ではありません。もう一つの誤用は、訓練されていないレビューアーを投下して品質向上を期待することです——仕分けなきノイズは、ブルックスの法則に馴染みの協調コストを再現します。よくある誤解
スローガンと、それを真にする条件を分けます。リーナスの法則は、人気オープンソースに深刻なバグがないという意味だ
リーナスの法則は、人気オープンソースに深刻なバグがないという意味だ
いいえ。十分な能力あるレビューアーが見ているとき、特徴づけが速くなる、と予測します。レビュー覆いのない人気は、深いバグを何年も残し得ます。
Linus Torvalds が形式的定理として述べた
Linus Torvalds が形式的定理として述べた
いいえ。Eric S. Raymond が Torvalds の Linux 実践にちなんで命名・普及しました。Torvalds は発見と修正の区別を精緻化しましたが、数学的法則として発表していません。
GitHub のスターが多いほど目が多い
GitHub のスターが多いほど目が多い
いいえ。スターは注目の尺度であり、実行されたレビューではありません。コードを動かさず、危険なモジュールを読まず、issue も出さない目は、バグを浅くしません。
関連概念
これらのページは、協働の限界・インセンティブ・失敗パターンのなかにリーナスの法則を置く助けになります。ブルックスの法則
人を増やすと協調コストが上がり得る——コミュニケーションが回るときだけ、目は役立つ。
カニンガムの法則
誤った主張は訂正を招く；公開露出と応答の近縁ダイナミクス。
ハイラムの法則
利用者はあらゆる観測可能な振る舞いに依存する——「十分な目」が挑まなかったバグ含む。
ポステルの法則
寛容は相互運用を助けるが、レビューアーがなお検査すべきプロトコルの癖を隠し得る。
マーフィーの法則
起きうる失敗はなお起き得る——精査は驚きを減らすが、失敗モードを廃止しない。
ガルの法則
動く複雑系は単純なものから育つ；早期露出は複雑さが欠陥を隠す前に捕まえ得る。