2026年8月25日、Linus Torvalds氏が新しいOSの構想をUsenetへ投稿してから35年を迎えた。この日はコードを公開した日ではない。Torvalds氏はMinix利用者に欲しい機能を尋ね、開発中の仕組みを紹介しただけだった。最初の版であるLinux 0.01がアップロードされたのは9月17日である。そこから35年、1人の実験は7万を超えるソースファイルを数千人で更新するプロジェクトへ変わった。
記念日の9日前には、最新mainlineのLinux 7.2が公開された。Linuxは完成品を保存してきたのではなく、開発者と製品の変化を取り込み続けてきた。長寿を支えたのは、最初の設計を守り抜く力より、設計と担当者を入れ替えながら品質を確かめる仕組みだった。
ここでいうLinuxは、主にOSの中核でハードウェアと資源を管理するカーネルを指す。普段触れるLinuxディストリビューションには、シェルやライブラリ、デスクトップ環境など別のソフトウェアも含まれる。35年間の規模と開発手続きを比べるには、この境界をそろえる必要がある。
8月25日は「発表」、最初のコードは9月17日
1991年8月25日の投稿で、当時ヘルシンキ大学の学生だったTorvalds氏は、386/486 AT互換機向けに無料のOSを作っていると明かした。4月から開発しており、Bash 1.08とGCC 1.40が動作する段階まで来ていた。ただし本人の説明は「趣味」であり、GNUのように大規模で専門的なものにはならないというものだった。
投稿は成功物語の予告ではない。LinuxはMinixのコードを含まず、マルチスレッドのファイルシステムを備えていたが、386のタスク切り替え機構へ強く依存していた。Torvalds氏は移植性がなく、手元にあるATハードディスク以外を支える見込みも薄いと率直に書いている。
9月17日の0.01は、その制約をさらに具体的に示す。公式リリースノートによると、動作確認は2台だけだった。対応機器はハードディスクと画面のほか、キーボードやシリアル回線の一部に限られ、mountとumountも未実装。フィンランド語キーボードの配列はコードへ直接埋め込まれていた。ソースは読めてコンパイルもできたが、システムを立ち上げるにはMinixが必要だった。
386への密着は偶然ではない。0.01は同CPUのページングとセグメンテーションを直接使い、Minixのメッセージパッシングを採らず、システムコールを通常の関数呼び出しに近い形で処理した。狙いは移植性より、手元の機械で早く動かすことにあった。この割り切りが初期開発を前へ進めた一方、別のCPUへ広げる仕事は後の開発者に残された。
つまり、8月25日は人を集め始めた日であり、9月17日はコードを渡し始めた日である。Linuxには二つの「誕生日」があり、35周年の意味は最初の版が完成していたことではなく、未完成の状態で外へ開いたことにある。
9,877行から3,981万5,032行へ
XenoSpectrumは、kernel.orgが保存する0.01と7.2の公式tarballを同じ方法で集計した。Cとヘッダーファイルを数え、さらにアセンブリ、Rust、Device Treeを対象に加えた。コメントと空行を含む物理行数を比較した結果が次の表である。
| 項目 | Linux 0.01 | Linux 7.2 |
|---|---|---|
| 公開日 | 1991年9月17日 | 2026年8月16日 |
| ソース系ファイル | 83 | 71,934 |
| ソース系の物理行数 | 9,877 | 39,815,032 |
| 対象アーキテクチャ | 386 AT機に密結合 | arch/直下に21系統 |
7.2のソース系の物理行数は3,981万5,032行で、0.01の約4,031倍に当たる。ファイル数も約867倍になった。初期版で「移植できない」とされたカーネルは、現在のソースツリーではx86に加えてArm、RISC-V、PowerPC、s390などを別々のディレクトリで扱う。初期の制約を保存したのではなく、各世代の開発者が交換してきた結果である。
全ファイルで見ると、0.01の88ファイルに対して7.2は9万4,744ファイルある。本文の表をソース系ファイルへ絞ったのは、文書やビルド設定まで含む総行数では、何を比較しているかがさらに曖昧になるためだ。それでも言語や記述方法は時代で異なる。約4,031倍は、同じ入口から見た規模の差であり、開発生産性の差ではない。
もっとも、行数は品質や普及度を測る数字ではない。7.2には新しいアーキテクチャやドライバーに加え、テスト、文書、互換性維持のためのコードも積み重なる。約4,000倍という値は、維持すべき表面積がどれほど広がったかを示す。増えたコードを誰が読み、どの変更を入れるかという問題も同じだけ重くなる。
実際、公式のChangeLog-7.2には、7.1から7.2までの範囲で1万7,833件のコミット見出しがある。カーネルの開発文書が典型例として挙げる約1万3,000件を上回る規模だ。35周年は回顧の節目であると同時に、大量の変更を取り込み続ける現役プロジェクトの通過点でもある。
ただし、mainline 7.2は利用者の機器へ一斉に届く製品版ではない。ディストリビューションや機器メーカーはstable版や長期保守版を選び、必要な修正を組み合わせて提供する。mainlineの速い更新と、製品で求められる長期の互換性を分けて運ぶことも、Linuxが幅広い用途へ広がれた理由である。
有償配布禁止を外し、1人の判断を委任した
0.01の配布条件は現在と同じではなかった。完全なソースを入手可能にし、著作権表示を残す一方、有償での配布を禁じていた。0.12のリリースノートでTorvalds氏はこの禁止を外し、GNU copyleftと互換にする方針を示した。7.2のCOPYINGは、Linuxカーネル全体をGPL-2.0-onlyとLinux-syscall-noteの下で提供すると定めている。
有償配布を認めたことで、Linuxを含む製品を料金付きで再配布する際の障害が一つ消えた。ただし、この変更が企業による上流貢献を自動的に生んだわけではない。企業の開発者も公開レビューへ参加し、改良をmainlineへ届ける。その受け皿になったのは、次に述べる分散した開発手続きである。
開発手続きも1人で判断する方式から離れた。公式文書によると、現在は1年間に約2,000人の開発者が関わる。パッチは担当メーリングリストでレビューされ、サブシステムのメンテナーが選び、上位のメンテナーを経てmainlineへ届く。Torvalds氏へ直接すべてを送るのではなく、信頼を段階的につなぐ方式である。
この委任には時間の枠もある。新機能を取り込む約2週間のmerge windowが閉じると、release candidateを重ねて回帰を減らす。安定版の公開後はstable teamが重要な修正を戻す。規模が増えても公開頻度を保てるのは、開発、選別、安定化を別の仕事として回しているからだ。
次の35年もレビューを続けられるか
Linux 0.01は、速く動かすために386へ密着し、支援できる機器を絞った。7.2は21のアーキテクチャ系統を抱え、1回の開発サイクルで1万7,000件を超える変更を受け入れる。前者と後者をつなぐのは、最初から正しかった設計ではない。誤りや制約を見つけた人が、公開の場で直せる仕組みである。
一方で、分散してもレビューの負担は消えない。新しいファイルが増えれば担当者の専門知識が必要になり、古いコードを残せば回帰を見抜く経験が要る。コードを書く人数が増えた現在、変更を受け入れる判断と、長年の担当者から次のメンテナーへ知識を渡す作業を継続できるかが判断材料になる。
35年前の投稿は、欲しい機能を利用者に尋ねる短い呼びかけだった。次の35年も更新を続けられるかは、1万件単位の変更を読む人と、責任を引き継ぐメンテナーを確保できるかで測れる。Linux 7.2以降を見るときは、コミット数と同時に、レビューと引き継ぎの仕組みが維持されているかを確かめる必要がある。