Linuxの創造主、Linus Torvalds氏が、Googleのエンジニアから提出されたRISC-V関連のコードを「ゴミ（garbage）」と一蹴し、プルリクエストを却下した。この出来事は、オープンソース界の巨頭が、品質と規律に対する揺るぎない姿勢を改めて示したものとして、大きな波紋を呼んでいる。
静寂を破った「ゴミ」発言
事件が起きたのは、Linux 6.17カーネルのマージウィンドウ（新機能を取り込む期間）が閉じようとしていた2025年8月8日金曜日のことだ。GoogleのAndroidチームに所属するエンジニア、Palmer Dabbelt氏が、次期カーネル向けのRISC-Vアーキテクチャ関連の機能追加を求めるプルリクエストを提出した。
これに対し、週末にかけてTorvalds氏から返されたのは、彼の代名詞とも言える、率直かつ痛烈な拒絶の言葉だった。Linuxカーネルメーリングリストに投じられた彼のメッセージは、一切の遠慮がなかった。
「ノーだ。これはゴミだし、提出が遅すぎる。私は旅行中だから早期のプルリクエストを求めたはずだ。そのルールに従えないのなら、せめてプルリクエストを良いものにしろ」
Torvalds氏の怒りの矛先は、主に2つの点に向けられていた。提出のタイミングと、コードそのものの品質だ。彼は、問題のコードがRISC-Vに特化していない「様々なゴミ」を汎用的なヘッダーファイルに追加しようとしていると指摘し、「『ゴミ』というのは本気で言っている。こんなものは誰も私に送るべきではないし、ましてやマージウィンドウの終盤に送るなど論外だ」と断じた。
このプルリクエストは即座に却下され、Linux 6.18のサイクルで、品質を改善した上で「早期に」再挑戦するよう通告された。オープンソース界の頂点で行われたこの厳しいやり取りは、瞬く間に技術コミュニティに広まり、様々な議論を巻き起こしている。
「世界を積極的に悪くする」とまで断じたコードの核心
Torvalds氏は単に感情的に罵倒したわけではない。彼の批判は、極めて具体的かつ技術的な根拠に基づいている。今回の「ゴミ」発言の核心を理解するには、その中身を詳細に分析する必要がある。
問題の本質：可読性を損なう「無意味なヘルパー関数」
Torvalds氏が最も痛烈に批判したのが、make_u32_from_two_u16()というヘルパー関数だ。これは、2つの16ビット整数（u16）から1つの32ビット整数（u32）を生成するためのもの。一見すると、複雑な処理を単純な関数呼び出しにまとめる、ごく一般的なプログラミング手法に見えるかもしれない。
しかし、Torvalds氏はこれを「狂っていて無意味」「世界を積極的に悪くするもの」とまでこき下ろした。なぜか。
彼が指摘するのは、可読性の問題だ。彼によれば、同じ処理を (a << 16) + b と直接記述すれば、プログラマは a が上位16ビット、b が下位16ビットを構成することを一目で理解できる。ビットシフトと加算という、コンピュータサイエンスの基本的な演算によって、処理内容が自明になるからだ。
「対照的に、make_u32_from_two_u16(a,b) と書いた場合、引数の順序がどうなっているのか、さっぱり見当がつかない。言い換えれば、物事を悪化させているだけだ」
優れた抽象化はコードを劇的に改善するが、不適切な抽象化は、その意図を隠蔽し、将来のデバッグやメンテナンスを困難にする「負債」となる。このヘルパー関数は、まさにその典型例だった。どちらの引数が上位でどちらが下位なのか、関数定義をわざわざ確認しに行かなければならない。これは、コードを読む側の認知負荷を不必要に増大させる。Torvalds氏の言う通り、これは「stupid “helper”（愚かなヘルパー）」であり、むしろ使わない方がマシなのだ。
「縄張り」の侵害：汎用ヘッダーファイルの汚染
もう一つの重大な問題は、この無意味なヘルパー関数が、RISC-V固有のディレクトリではなく、カーネル全体で共有される「汎用ヘッダーファイル」に追加されようとしていた点だ。
これは、Linuxカーネル開発における重大な作法違反と言える。カーネルは、アーキテクチャ、ドライバ、ファイルシステムなど、無数のサブシステムから構成される巨大なソフトウェアだ。その秩序を保つため、各サブシステムは、自身の変更を可能な限り自身の管理するディレクトリ（ツリー）内に留めることが求められる。共通の領域を変更する場合は、それが本当に汎用的で、多くのサブシステムにとって有益であるというコンセンサスが必要だ。
RISC-Vのためだけに作られた、しかも品質の低いヘルパー関数を汎用領域に置くことは、他の開発者にまでその「ゴミ」を使うことを推奨するに等しい。Torvalds氏はこれを「クレイジーなもので汚染する」と表現し、断固として拒否した。これは、自身の家の庭の手入れを怠るだけでなく、共有の公園にゴミを捨てるような行為であり、コミュニティ全体の資産を損なう行為と見なされたのだ。
規律の欠如：締め切り間際の「滑り込み」
技術的な問題に加え、プロセス上の問題もTorvalds氏の怒りを買った。彼は旅行の予定があるため、マージウィンドウの早い段階でプルリクエストを提出するよう事前にコミュニティに要請していた。にもかかわらず、Dabbelt氏のプルリクエストは、締め切り前日の金曜日に提出された。
締め切り間際の大規模なプルリクエストは、レビュー時間が十分に確保できないため、バグや質の低いコードが紛れ込むリスクを高める。Torvalds氏は、「マージウィンドウが閉じる前日に大きなプルリクエストを送れば、私が忙しくて気にしないだろうと期待するのは、勝利の戦略ではない」と釘を刺した。これは、開発プロセスにおける規律と、他の開発者への敬意を問う、極めて重要な指摘である。
単なる「癇癪」か、合理的な「品質管理」か
Torvalds氏のこの種の厳しい物言いは、今に始まったことではない。彼の「炎上」は、Linux開発の歴史の一部と言ってもいい。この彼のスタイルは、常に賛否両論を巻き起こしてきた。
Linus流コミュニケーションの功罪
彼のオブラートに包まない物言いやそのコミュニケーションは、技術的な問題を曖昧にせず、核心を突くという利点がある。何を修正すべきかが明確に伝わり、コミュニティ全体に対する強い警告として機能することで、プロジェクト全体の品質と規律を維持する上で大きな役割を果たしてきたことは間違いない。
一方で、その攻撃的な言葉遣いは、開発者を萎縮させ、特に新規参入者にとっては高い障壁となりうるという批判も根強い。オープンソースの精神であるはずの、オープンで包括的なコミュニティ形成を阻害するという見方だ。
実際、Torvalds氏自身もこの問題を認識しており、2018年には一時的に開発の第一線から退き、自身の行動を見つめ直す期間を設けたことがある。それ以降、彼のコミュニケーションは個人攻撃を避け、コードそのものへの批判に集中する傾向が強まったとの見方もある。
今回の件も、Dabbelt氏個人を攻撃するものではなく、あくまで提出された「コード」と「プロセス」に対する純粋な技術的・運営的批判であると解釈するのが妥当だろう。彼の言葉は辛辣だが、その根底には、Linuxという自身が生み出したプロジェクトに対する並々ならぬ愛情と、品質に対する一切妥協しないという哲学が一貫して流れている。
舞台裏のプレイヤー：GoogleとRISC-Vの現在地
この一件をより深く理解するためには、当事者であるGoogleと、対象となったRISC-Vアーキテクチャが置かれている状況にも目を向ける必要がある。
オープンな未来を描くGoogleとRISC-V
RISC-Vは、特定の企業が所有しない、オープンスタンダードな命令セットアーキテクチャ（ISA）だ。誰でも自由に利用・拡張できるため、Armやx86といった既存のプロプライエタリなアーキテクチャへの依存から脱却を目指す動きの中で、近年急速に注目を集めている。
Googleは、このRISC-Vの主要な推進者の一つだ。Androidエコシステムにおいて、ライセンス料のかかるArmからの代替選択肢としてRISC-Vを公式にサポートし、その採用を強力に後押ししている。今回プルリクエストを送ったDabbelt氏がGoogleのAndroidチームに所属していることは、まさにその戦略の最前線にいることを示唆している。Googleにとって、RISC-Vは単なる技術的選択肢ではなく、モバイルからデータセンターに至るまで、コンピューティングの未来をよりオープンで自由なものにするための戦略的基盤なのだ。
Linuxカーネルにおける「新参者」の試練
一方で、Linuxカーネルの世界において、RISC-Vはまだ比較的新しいアーキテクチャだ。x86やArmが数十年にわたって積み上げてきた実績と安定性に比べれば、まだ発展途上の段階にある。
そのため、RISC-Vのサポートは日々活発に開発が進められており、多くの機能追加や変更が試みられている。今回のプルリクエストも、ACPIサポートの強化やパフォーマンス改善など、RISC-Vをより実用的なものにするための重要なステップだったはずだ。
しかし、新興アーキテクチャであるがゆえに、そのコードはより厳しい精査の目に晒される運命にある。確立された作法や標準から逸脱したコードは、カーネル全体の安定性を損なうリスクが大きいと見なされやすい。今回の厳しい拒絶は、RISC-Vコミュニティに対し、Linuxカーネルという巨大で複雑なエコシステムの一員となるためには、より高いレベルの品質と規律が求められるという、明確なメッセージを送ったとも言えるだろう。
コード一行に宿るOSSの哲学と未来への教訓
Linus Torvalds氏による「ゴミ」発言は、表面的に見れば単なる開発者間の衝突に過ぎない。しかしその奥には、20年以上にわたり世界で最も重要なソフトウェアの一つであり続けるLinuxカーネルの、品質維持メカニズムそのものが凝縮されている。
これは、コードの品質、可読性、保守性、そして開発プロセスにおける規律の重要性を、コミュニティ全体に再認識させるための、強烈な「公開授業」だったのではないだろうか。Torvalds氏は、絶対的な権限を持つ「優しい終身の独裁者」として、時に厳しい言葉を使いながらも、プロジェクトが正しい方向に進むよう舵を取り続けている。
幸いなことに、この一件は破壊的な結末を迎えてはいない。GoogleのエンジニアであるDabbelt氏は、Torvalds氏の指摘に対し、「これ以上遅れないようにします。それが品質問題の助けになることを願っています」と、建設的かつ和解的な返信をしている。この迅速な反応は、コミュニティの持つ自己修復能力の高さを示すものだ。
今回の摩擦は、短期的には痛みを伴うかもしれない。しかし、これを乗り越えることで、RISC-VのLinuxにおける実装はより洗練され、GoogleとLinuxコミュニティの関係もまた、より成熟したものへと進化していくはずだ。一行のコードを巡るこの激しいやり取りは、オープンソース開発が単なるコードの集合体ではなく、人間的な情熱と厳しい規律、そして共通の目標に向けた絶え間ない対話によって成り立っていることを、我々に改めて教えてくれる。
ポチップ
Sources
