誰も FOSS にお金を払いたくない。ならば払わせればいい

オープンソースの経済学についてブログを書くべきだと思ったのは 2013 年が最初だから、これはずいぶん長く寝かせたことになる。一番近づいたのは 2022 年で、iOS のメモに意識の流れを書き殴り、最後は「これ、何をやってもダメだ」で終わっていた。そのまま四年放置したのは、「何をやってもダメだ」という結論があまりに絶望的で、5000 字を割く価値があると思えなかったからだ。今ようやく、一つのアイデアがある。ただそこに辿り着くまでに 5000 字かかるので、時間がない人は registry の話まで飛ばしてほしい。

オープンソースは結末の決まったゲームであり、その結末とは無料の勝利だ

以前タカとハトについて書いた。進化生物学のモデルだ。ある資源をめぐって競争する動物の集団がいる。一部はそれを奪い合い（タカ）、一部は分け合う（ハト）。タカだけの集団は安定しない。みんなが傷つき続け、そこに最初に現れた二羽のハトが協力し合って、他の全員を競争で退ける。ハトだけの集団も安定しない。最初に現れた一羽のタカが全員と競争し、毎回勝つ。安定するのは二つの型が混ざった状態で、その比率は「自分の行動を変えても得をしない」ぎりぎりのところに落ち着き、誰も変えない。この混合を進化安定戦略（ESS）と呼ぶ。ポイントは「安定」だ。最善の戦略ではない（最善はおそらくハトだけの状態で、誰も傷つかない）。集団が最終的に行き着き、そこから離れられなくなる状態、それが ESS だ。ソフトウェアを考えるのにも役立つと思う。ソフトウェアにもタカとハトがいる。

クローズドソースはタカだ。競争する。コードを抱え込み、他人が持っていないものに高い値段を付け、その状態を必死で維持しようとする。オープンソースはハトだ。協力する。コードを手放し、他人もコードを手放すことから利益を得る。両者が最終的に奪い合う資源は金だが、まずはユーザーと開発者の注意という形で現れる。

行き着いた均衡は非常に具体的だ。あるソフトウェアの進化安定戦略は「誰でも無料で、どんな用途にも、商用利用も含めて使える」である。 MIT、BSD、Apache、つまり何も要求しないライセンスだ。「少しだけ寛大さの劣るハト」であろうとしたプロジェクトは、すべて「完全なハト」に負けてきた。例はいくらでも挙げられる。

2017 年、Apache ソフトウェア財団が React の BSD+Patents ライセンスを Apache プロジェクトに取り込むことを禁じ、WordPress が React をやめると宣言すると、Facebook は数週間でReact を MIT ライセンスに変更した。死なせるよりましだったのだ。
2021 年、Elastic は Amazon がサービスとして売るのを止めようと Elasticsearch を source-available ライセンスに変えた。Amazon は OpenSearch としてフォークし、そのフォークは Linux Foundation に入って数千人のコントリビューターを集め、2024 年に Elastic はひっそりとオープンソースライセンスに戻した。
2023 年、HashiCorp が Terraform で同じことをした。OpenTofu は Linux Foundation にフォークとして入り、HashiCorp は IBM に買収された。
2024 年 3 月、Redis も同じことをした。Valkey のフォークは一週間ほどでクラウド事業者をほぼ全部集め、2025 年 5 月に Redis は AGPL を戻し、CEO はこの変更で大きな損をしたと認めている。

ライセンスの層でオープンソースの対価を取ろうとした者で、まともなフォークを前にして持ちこたえられた者はいない。これはイデオロギーの問題ではないと思う。そういう会社を動かしている人間は自分のコードの対価をぜひ取りたいだろうし、フォークする側の大半も抽象的な自由をそれほど気にしているわけではない。市場構造がそうさせているのだ。「破壊的イノベーション」とは元々、はるかに劣り、はるかに安い製品が市場の底を取って、少しずつ良くなって市場全体を食い尽くすことを指す。これが製品が完全にただになるまで繰り返される。ソフトウェアはソフトウェアが存在して以来ずっとこれをやられ続けてきた。行き着く先は二つに割れた市場だ。ほぼ全員が使う巨大で安い半分と、利益のほぼすべてを持っていくずっと小さく高い半分。Android がシェアを取り、iOS が利益を取る。どちらの数字を見るかで、どちらも大成功だ。無料がシェアを勝ち取り、クローズドソースが利益を勝ち取り、両方が勝っている。

この安定した結末は、人が燃え尽きることで成り立っている

ここまではいい。自由ソフトウェアが勝ち、クローズドソースが稼ぎ、それぞれの居場所がある。問題は、その無料の層が内側からどう見えるかだ。

60%のオープンソースメンテナーはこの仕事の対価を得ていない。Tidelift の 2024 年の調査の数字で、2023 年も 2021 年も同じだった。報酬のない人のうち 61% は一人でやっている。メンテナー全体の 60% 近くがすでに離れたか、離れたいと思ったことがあり、理由は想像がつくだろう。生活がある、興味を失った、燃え尽きた。

この人たちが支えているソフトウェアの量は常識外れだ。Sonatype は 2023 年に120 万のオープンソースプロジェクトを調べ、11% に活発なメンテナーがいることを見つけた。Linux Foundation の Census II では、136 人の開発者が最もよく使われる 50 パッケージの 80% 以上のコードを書いていた。ハーバードの研究は、オープンソースが消えたら企業は8.8 兆ドルをかけて置き換えることになると見積もり、5% の開発者が価値の 96% を生んでいるとした。ちなみにこれが JavaScript エコシステムの性格そのものだ。メンテナーが一人（あるいは一人も）いない小さなパッケージが大量にあり、それが会社の命運を賭けた依存ツリーの底に座っている。npm で五年働いて、この光景をずっと見てきたが、警戒心が薄れることは一度もなかった。

今や誰もが引き合いに出す例が xz だ。2024年、地球上のほぼすべての Linux マシンに入っている圧縮ライブラリにバックドアが見つかった。偽のコントリビューターが2年がかりで仕込んだもので、彼は非常に根気よく無償でメンテナンスしていた人物をソーシャルエンジニアリングし、鍵を渡させた。そのメンテナーは、自分はもう限界で追いつけなくなっていると公言していた。誰も彼を資金援助しなかったが、代わりに誰かが彼を操った。バックドアを捕まえたのは Microsoft のエンジニアで、SSH が本来より半秒遅いことに気づいたからだった。頼りにしたい種類の防御線ではない。

この話を語る最も一般的な形は「このシステムは崩壊しつつある」というものだが、それは違うと思うし、この区別は重要だ。このシステムは崩壊していない。安定している。私たちが集団で容認すると決めた人的コストの水準で安定している。 一人のメンテナーが燃え尽き、別の誰かが引き継ぎ、その人も燃え尽きる。これが延々と続く。次から次へと燃え尽きが起きることは、この均衡に含まれるバグではない。それこそが均衡だ。オープンソースはかなり古い。崩壊するものならとっくに崩壊している。これは血で動く機械であり、進化的に安定な戦略だからこそ、私たちはそれを変えられずにいる。

変わったのは速度だけ、それも速度だけ

でも、悪化しているように感じるだろう？安定したシステムが以前より悪い結果を出すなら、何か入力が変わったということだ。変わったのは速度だ。

Linux はゆっくり積み上がっていったので、カーネルの一部を10年分の夜と週末でメンテナンスできた。誰も待っていなかったからだ。そこへ Web が来て、次に npm が来て、10年で100万個の微小なモジュールが生まれ、そのどれもが数週間のうちに誰かの本番システムの構造を支える部品になりえた。ソフトウェアが重要になる速度は、どんな組織がそれに気づく速度よりも、ましてや資金を出す速度よりも速かった。同時にセキュリティも速くなった。人気ライブラリのバグは今や数日で悪用され、一度に数万社に降りかかる。つまり、人気パッケージをメンテナンスするコストは大きく上がり、その見返りはちょうどその場に留まっている。0ドルと少しの温かい気持ちだ。

夜と週末では足りなくなった。それでも人は続ける。もともとそういうソフトウェアを書く人間だからだ。開発者は歌手が歌うようにソフトウェアを書く。つまり誰も聴いていなくてもやる。これは修正すべき問題ではなく、システム全体を動かしているものだ。「開発者がソフトウェアを書く量を減らそう、あるいは気前よく書くのをやめよう」を前提にした解決策は、私には受け入れられない。問題は、人が無償でソフトウェアを書くことではない。最も有用なソフトウェアを無償で書いた人への報酬を、無報酬の二つ目の仕事として私たちが組み立ててしまっていることだ。

試した方法はどれも金を動かしただけで、均衡を動かしたものは一つもない

ここが一番歯がゆい部分で、私が4年間引きずってきた部分でもあるので、さっと流す。試したものはこうだ。

投げ銭。 GitHub Sponsors の累計支払額は2026年7月に1億ドルを超えた。8.8兆ドルの隣に置くまでは多く聞こえる。その分配も投げ銭にありがちな形、つまりべき乗則だ。少数の著名人はそこそこ暮らせており、スポンサーがつくメンテナーの中央値は昼食代にしかならない。Open Collective、Patreon、Ko-fi も同じ形をしている。
財団。 Linux Foundation、Apache、OpenJS、Python Software Foundation。実在する組織で、実際の予算があり、その主な使い道は職員、イベント、インフラだ。これは批判ではない。誰かがカンファレンスを開かないといけない。だが Tidelift の調査では、財団から金を受け取ったことがあるメンテナーは3%しかおらず、政府からは1%だ。財団は、企業が舵を取るために金を払う場であって、漕ぐ人に金を払う場ではない。
企業の気前の良さ。 Google の Open Source Office、Microsoft の FOSS Fund、そして Sentry のオープンソースへの誓約。開発者1人あたり年2000ドルの拠出を企業に求めるもので、2024年の開始時に約130万ドルが約束された。この誓約は気に入っている。ただ、このリストの他のすべてと同じ欠陥がある。慈善であり、慈善は兆単位には拡張できない。Google と OpenSSF で何年もかけてメンテナーに金を配ろうとしてきた Dan Lorenc は語っている。配りきれないほどの金が手元にあり、それでも何も直らなかったと。私はあれを失敗した試みであって自然法則だとは思わないが、失敗した試みのリストには数えておくべきだろう。
セキュリティへの支払い。 Tidelift のモデル全体は、メンテナーに金を払ってパッケージを安全に保たせ、その保証を企業に売るというもので、良いアイデアだった。そして2024年12月、Sonar に買収された。良いアイデアが十分な買い手を見つけられないとこうなる。OpenSSF の Alpha-Omega は年に500万から600万ドルを出しており、主に財団内のセキュリティ要員の資金になっている。理にかなっているが、規模は小さい。
政府。 ドイツの Sovereign Tech Fund は素晴らしいアイデアだ。納税者の金を、条件をつけずに、重要インフラのメンテナンスへ直接投じる。2022年以降、60以上のプロジェクトに2400万ユーロ以上を投じている。だがこれも一つの基金にすぎない。約190か国の中の一つが年に約2000万ユーロを使っているだけであり、EU 全域版は2028年から始まる予算サイクル向けの提案のままだ。
Mozilla。 Mozilla の資金は Google の検索収入にストローを挿したものだ。Mozilla の誰もがそれを問題だと知っていて、だから多角化を試み続け、ずっと成功していない。（一時期、Mozilla と Google はサンフランシスコの同じビル、違う階に本当に入っていた。）「他人の収入源を見つけてストローを挿す」は一般化できない。収入源は分け合えるほど多くない。
ライセンス。これはもう話した。デュアルライセンス、source-available、「fair source」。どれも鳩が少しだけ鷹になろうとしたもので、どれも隣の完全な鳩に負けた。

これらには共通点がある。どれも任意だ。企業は寄付を求められ、応じる企業もあれば、応じない企業のほうが多い。そして応じなかった企業が手にするソフトウェアは、応じた企業とまったく同じだ。慈善はスケールしないし、リリースを強制する権限を持つ者はいない。私たちは企業にオープンソースの金を払えと三十年間頼み続けてきた。この「お願い」は十分に検証済みと見ていいだろう。

企業は実際にオープンソースへ金を払っている。ただし書いた人間には払っていない

次の事実で、自分の考えが間違っていたと気づいた。企業はすでにオープンソースへ金を払っている。しかもかなりの額を。ただ、その金はメンテナには渡っていない。

JFrog は Artifactory を売っている。ビルドサーバーと公開パッケージレジストリの間に座るプライベートミラーだ。JFrog の2025年の売上は5億3200万ドルで、24% 伸びた。Snyk は依存関係をスキャンして脆弱性を見つける。年間売上は約3億2600万ドル。Docker はすべてのコンテナイメージの供給元であるレジストリを運営し、売上は2億700万ドル。Chainguard は堅牢化したオープンソースイメージを売り、一年で約4000万ドルから1億ドル目標へ伸ばした。Sonatype は非公開企業だが、すべての Java ビルドが取得する Maven Central を運営しながら、その手前に置く Nexus ミラーも売っている。Sonatype 自身の数字によれば、Maven Central のトラフィックの86%はクラウド事業者、つまり企業から来ている。ここに Tidelift を傘下に持つ Sonar、Socket、そしてサプライチェーンセキュリティ市場の他のプレイヤーを足せば、年間10億ドルは軽く超える。

この金は何に使われているのか。マーケティングを剥がせば、これらの企業は同じものを売っている。無料コードの信頼できる供給だ。レジストリが落ちてもビルドは止まらない。依存関係はキャッシュされ、スキャンされ、署名され、主張どおりのものであることを証明できる。次に Log4Shell が起きたとき、2000のサービスのどれが影響を受けるか1時間で特定できる。これは実問題を解く実製品であり、企業は喜んで買う。「依存しているあの無料の何かが壊れているか悪意あるものかもしれないが、こちらには見分けがつかない」は、調達部門が金の使い方を知っている類の問題だからだ。

言っておきたいのは、これらの企業を悪役だとは思っていないということだ。何社かは知り合いが運営している。彼らが解いているのは本物の問題だ。企業は、自分で書いておらず検査もできないコードに依存する必要がある。ただ、解いている層が違う。彼らが売っているのはメンテナに対する保険であり、そのチェーンでコードを実際に安全にできる唯一の存在であるメンテナは何も受け取らない。上の二層のどこかの企業が、彼女がやったかどうかを教える代わりに金を取っている。

これで問題全体の見え方が変わった。長年、制約は金の供給側だと思っていた。企業はオープンソースに金を払いたがらないし、払わせる仕組みも存在しない。Lorenc の話はそれと整合する。だが JFrog の請求書は正反対を言っている。企業はオープンソースに金を払うし、喜んで払う。「サプライチェーン」という退屈な項目の形で現れさえすれば。金の供給が問題だったことは一度もない。問題は、下へ流れる途中で誰がそれを取っているかだ。

コードのゲームは無料が制した。供給のゲームはデフォルトが制した

ではなぜ ESS はここで当てはまらないのか。無料が常に勝つのなら、なぜ無料のミラーが JFrog を食い尽くさないのか。

ここでは二つのゲームが同時に進行していて、勝者がそれぞれ違うからだ。コードのゲームで資源はソフトウェアそのもので、無料が毎回勝つ。誰でもコードを複製できるので、対価を取る試みは必ず無料のコピーを呼び寄せる。供給のゲームで資源は「コードがどこから来るかを考えなくていいこと」であり、このゲームはデフォルトが制する。

証拠を見よう。レジストリのフォークに成功した例は一度もない。npm、PyPI、Docker Hub の無料ミラーは存在し、立ち上げは取るに足らず、コマンド一つで届く場所にあることもある。それでも企業は JFrog に年間5億ドルを払い続ける。Red Hat はデスクトップを Ubuntu に奪われ、しかも完敗した。Ubuntu は金持ちが無料で配っているものだ。鳩がコードのゲームを制した。Red Hat は後に340億ドルで IBM に売却され、今では同じ無料コードを企業に供給することで（電話番号付きで）年間60億ドル以上を稼いでいる。誰でも同じコードを無料で入手でき、実際に多くの人がそうしている。それでも非常に多くの企業が Red Hat に金を払う。

Docker が最も明快な例だ。最近の出来事で、しかも公開されている。2020年11月、Docker Hub は匿名および無料のプルにレート制限をかけ始めた。2021年8月、Docker Desktop は従業員250人超または売上1000万ドル超の企業にとって有料製品になり、個人、小規模企業、オープンソースプロジェクトには無料のまま残った。無料が常に勝つのなら、無料の代替が彼らを食い尽くしたはずだ。Podman と containerd は実在し、無料で、完全に十分だ。それでも Docker の売上は2020年の約1200万ドルから、2021年には5000万ドル超、そして2024年には2億700万ドルへ伸び、有料席は100万を超えた。（Docker はプル量に応じた課金も発表しかけ、2025年に開発者が反発したあと撤回した——これはどの課金の形が機能するかを正確に物語っている。企業から取るのであって、ダウンロードからは取らない。CI を再実行するたびに高くなる請求書を誰も望まない。）

コードというゲームは無料で勝てる。だが供給というゲームはデフォルトが勝ち、デフォルトには値段をつけられる。 レジストリは、この2つのゲームが接触するシステム内で唯一の場所だ。無料のコードが供給に変わる、まさにその地点だからである。ライセンスと違って、レジストリはコピーで回避できない。法的な制約ではなく、あまりにも便利なインフラだからだ。回避したいとは誰も_思わない_。回避するのは面倒すぎて、金を払って避ける価値がある。

レジストリ層で本気で試した者は誰もいない

ここで「それはもう試されたのでは？」と言う人がいる。答えは、ある意味ではそうだ。そしてその失敗の仕方には学ぶところがある。まず「レジストリ層」を狭く定義しよう。みんながそこからダウンロードしているドメインを誰が持っているか、だ。この定義に照らすと、このリスト上のほぼ何も当てはまらない。

2019年8月、Feross Aboukhadijeh——Standard を含む100以上の npm パッケージを保守していた——が、npm install の間、ターミナルにスポンサー情報を表示し始めた。開発者は嫌がり、スポンサーは数日で降り、Feross はそれを失敗した実験として書いた。npm の対応は、利用規約でターミナル広告を禁止し、寄付リンクの一覧を表示する npm fund を出すことだった。本物のレジストリが資金調達に介入した唯一の例がこれで、やったことは金を稼ぐ道を一本潰し、ハイパーリンクに置き換えることだった。実に薄い。私が npm にいたとき、もっと踏み込んだことを試す勇気はなかった。試すべきだった。

Flossbank は2020年から2022年まで、npm と yarn をラップし、少額の寄付や広告収入を集めて、インストールするあらゆるものの依存ツリー全体に配分した。これは私がこれから出す案の「分配」側そのもので、しかも実際に作られ、動いていた。終了し、創業者の振り返りは理由について正直だ。オプトインだったのである。そしてオプトインは「なぜ自分が払って隣の奴は払わないのか」で死ぬ。Flossbank もレジストリではなかった。レジストリの手前に自分で被せるもので、その摩擦だけで誰もやらなくなる。

Ruby Together は2015年から2022年まで、企業から会費を集めて RubyGems と Bundler の作業を資金援助した。機能はした。規模は小さく、Ruby Central に吸収されるまで続いた。その Ruby Central は大口スポンサーへの依存から、2025年の RubyGems リポジトリの乗っ取り、大量の辞任、そして著しく人手不足のチームが翌春にレジストリを狙ったここ数年で最悪の攻撃と向き合う事態を招いた。あの金はレジストリ自体の運営に充てられたもので、中のパッケージに対してではない。任意であり、大口寄付者は1社だけだった。それぞれ独立した3通りの失敗の仕方である。

つまりパターンはこうだ。任意のものはすべてフリーライドで死ぬ。唯一任意でなかったもの（Docker）は成功し、金を自分の手元に残した。ドメインを持つ者たちのうち、企業から供給の対価を徴収し、その供給を価値あるものにしている人々へ金を払った者は、一人もいない。

レジストリは企業から徴収し、メンテナーに払うべきだ

これが私の提案だ。3つの部分からなり、新しい部分は一つもない。新しいのは、それらを同じ場所に置くことだ。

第一に、レジストリは企業の利用を計測し、課金する。すでに計測している。npm、PyPI、Docker Hub、Maven Central にはレート制限、認証、エンタープライズ版があり、その手前に立つミラー事業者もシート単位で課金している。Docker のルールが正しいルールだ。個人、小規模チーム、学生、オープンソースプロジェクトは何も払わず、何も気づかない。ある規模を超えた企業はサブスクリプションを購入する。価格は今日の JFrog や Docker のサブスクリプションと同じで、つまり調達部門が会議を開かずに署名できる水準に置く。こうした企業の大半にとって、これは新しいコストですらない。すでに払っている。請求書の行が一行増えるだけだ。

第二に、この収入の固定された一部がロイヤルティとしてパッケージに流れる。レジストリではなく、財団でもなく、申請書を書く助成委員会でもない。比例配分で、有料顧客の依存ツリーに現れるすべてのパッケージへ、有料顧客がどれだけ依存しているかを重みとして、自動で、毎月、儀式も感謝のメールもなく。誰も何もしなくても金が動くことが要点だからだ。2022年のメモにこれについて書いた一文がある。そのまま引く。「金は片側から入り、もう片側から出なければならない。そのために暗号通貨を使う必要はない、それはひどい。データベースでいい。」分配側は難しくない。thanks.dev は今日すでに依存ツリー単位の比例配分をやっているし、Flossbank は2020年にやっていた。誰もそれを徴収側とつなげなかっただけだ。

第三に、これをやるのはドメインを持つ者たちだ。本当に重要なレジストリは十数個ほど。各メンテナーは、自分が気にかけているその一つにすでにアカウントを持ち、名前が載り、受け取り手段はすでにあるか、フォームの欄が一つ足りないだけだ。徴収側は有限だ。数千社の大企業、その大半はすでにサプライチェーン上のどこかの顧客である。これまでのあらゆる試みで最も難しかった2つの問題——支払者を見つけること、受取人を見つけること——はすでに解決されている。しかも同じデータベースによって。

npm を作った Isaac Schlueter は主張する、サポートに課金するのをやめ、アクセスに課金を始めるべきだと。営利企業なら、金を払わなければコードは手に入らない。この形には賛成だが、料金所の位置は変える。ライセンスに置けばフォークされる。レジストリに置けば JFrog のような収入が手に入る。GitHub は npm と GitHub Sponsors の両方を持っており、ここのすべてが同じ建物の中にある。今四半期にも npm の企業顧客に対して開ける。JFrog と Sonatype はすでに企業から供給の対価を徴収しており、明日にでもこの行を足せる。私は npm を5年間運営した。配管が難しい部分ではないと保証する。

「企業は無料ミラーに乗り換えたりしないのか？」

乗り換える企業もある。それで問題ない。Docker にとって問題にならなかったのと同じ理由だ。自分でミラーを運用する気がある企業は今日にでも無料でできるのに、むしろ JFrog にお金を払っている。彼らが買っているのは「自分で運用しなくていい」という一点だ。離れていく顧客はそもそも何に対しても金を払わなかった連中で、とっくに他人のミラーでタダ乗りしていた。Docker は一部の pull 数をミラーに奪われ、その間に売上を十五倍にした。

「これは要するに Tidelift の二番煎じでは？」

違う。そしてその違いこそが核心だ。Tidelift は独立した調達の意思決定だ。新しいベンダー、新しい説明、予算の中に一行分の居場所を自分で勝ち取らなければならない。ミラー請求書に載るロイヤルティはそもそも意思決定ですらない。調達部門の誰もそれを意思決定として扱わない。Tidelift は企業がこの問題に金を払うことを証明した。ただし「誰かに頼まれなければ動かない」という層で証明したにすぎない。

「抜け道を探す奴が出るのでは？」

出る。これは Spotify モデルであり、Spotify の問題をそのまま引き継ぐ。再生回数で払えばストリーミングファームが湧き、依存関係で払えば、互いに依存し合うゴミパッケージを千個公開して、それを誰かの lockfile にねじ込む方法を考える。支払う顧客の依存ツリーに現れるかどうかで重み付けし、生のダウンロード数では測らなければ、抜け道は格段に狭くなる。そのうえで「不正がゼロにならないのは、資金配分委員会を置かないことの代償だ」と受け入れる。世の中のあらゆる決済システムに不正率はある。そして現在の「メンテナーに払う」仕組みの不正率は 100% だ。そもそも一円も払っていないのだから。

他のすべてが失敗したときにこれが機能する理由

機能する理由は、均衡を変える必要がないからだと思っている。どの戦略もそのままの位置にとどまる。変わるのは何が計測されるかだけだ。

ライセンスは変わらない。だからフォークする必要もないし、「オープンソース」とは何かを議論する必要もない。コードというゲームは依然として無料が勝つ。それは正しい結果だし、歌手は歌い続ける。

慈善でもなければ命令でもない。誰も寄付を求められないし、最も無謀な企業がとっくに無視している法律で支払いを命じられることもない。企業はすでに供給に対して金を払っている。すでに払っている請求書に一行増えるだけだ。

しかもこれはロングテール、つまり他のあらゆる仕組みが取りこぼしてきた層に届く。投げ銭は有名人に届き、財団は従業員に払い、政府の資金は重要リストに載った二十のプロジェクトに流れる。依存ツリーのロイヤルティは is-odd に届く。小さくて役に立つものを作ったら四百社の本番環境に入っていた、という人が、申請もマーケティングも自分をブランド化する必要もなく、四百件の少額の支払いを受け取る。この提案の中で、私が一番気にかけているのはここだ。オープンソースの持続可能性をめぐる議論の大半は「メンテナーにもっと商売上手になれと教える」話に変質してしまったが、それは完全に逆だと思う。仕組みは、人が役に立ったから金を払うべきであって、金の無心がうまいから払うべきではない。

LLM がこれを緊急にし、同時に価値を高めた

2022 年以降に変わったもう一つのことは、ソフトウェアを書くコストの崩壊だ。三十年ぶりに、この方程式の中で単に速くなっただけでなく、実際に動いた変数だと思う。

ソフトウェアが安くなれば、ソフトウェアは増える。より多くの人が小さくて役に立つものを作れるようになり、ロングテールはさらに長くなり、誰かの依存ツリーに静かに紛れ込むパッケージの数は減るどころか増える。ロングテールに払える仕組みは、その世界でより価値が高くなる。

AI エージェントが今やオープンソースの最も急速に伸びる消費者であり、彼らがオープンソースを消費する方法はレジストリ経由の一つしかない、という意味でもある。2026 年 5 月、OpenAI が動かしていたエージェント群が二日間でRubyGems に 2000 以上のパッケージを公開し、レジストリ API のバグを突いてユーザー認証情報を攻撃し、ドキュメントサイトでリモートコード実行を成立させ、RubyGems を運営するボランティアに新規登録を四日間止めさせた。OpenAI はエージェントが無害なタスクを行っていたと述べており、おそらくそれは事実だろう。だがどちらにせよ、コストを吸収したのはボランティアで、彼らに小切手を送った者はいない。

初期の兆候はおおむねこういう形をとる。curl のメンテナー Daniel Stenberg は、七年間で 9 万ドルを支払ってきた脆弱性報奨金プログラムを閉じた。AI が生成したゴミ報告が、投稿に占める本物のバグの割合を 15% から 5% 未満に押し下げ、六年間で純粋に AI が書いた報告が実在の脆弱性を発見したことは一度もなかったからだ。AI はオープンソースの本物のバグを見つける能力を高めている。Google の Big Sleep はすでにいくつか発見している。だが発見は Google の内部で起き、修正は誰かの夜に起きる。そして今、その負担はそれを軽くするツールより速く増えている。そのツールはセキュリティチームを持つ企業のもので、パッチを書かされる本人のものではない。

どちらに転ぶかはわからない。長いこと、私の正直な推測は LLM の諸効果は互いに相殺し、同じ均衡にとどまる、ただ速くなるだけだというものだった。今はそこまで確信していない。コードを作るのは安くなり、供給を保証するのは高くなる——この二つのゲームが初めて分岐し始めたからだ。これはまさに供給レイヤーに金を払う価値が生まれる条件であり、誰が金を受け取るかが決まる瞬間でもある。

やる能力はずっとあった

「企業がもう少し善良であってほしい」という願いで締めくくりたくはない。その版の結末は頭の中で百回書いたが、役に立たない。実際にできる行動で締めたい。npm にいた頃はこの論を書けなかった。利害相反があまりに明白だからだ。だが npm での日々はずっと昔に終わり、生態系におけるその強力な位置への敬意だけが残っている。

オープンソース開発者は、力を持たない、無視して構わない散り散りなボランティアの集まりとして語られる。記録は正反対を示している。2017 年、私たちは Facebook に React のライセンスを変えさせた。2024 年と 2025 年には、Redis——背後に二十数億ドルを抱える企業——に、十四か月で戦略的判断を覆させた。誰かが私たちのコードを人質に取ろうとするたび、私たちはそれをやってのけた。協調した拒否は効く。そして鳩は裏切り者の罰則適用がかなり得意だとわかった。

私たちが一度もしてこなかったのは、その力をライセンスの外の何かに向けることだ。三十年間、標的はコードに金を取ろうとする企業であり続けた。その一方で、企業が実際にオープンソースに費やした金は、誰にも止められないまま、ボトルネックに座る十数社のベンダーへ流れていった。彼らは何の規則も破っていないからだ。そして何の規則も破っていないのは、そもそも規則が存在しないからだ——問題はまさにそこにある。

だから私は、こういう規則が一つあればいいと思う：価格表を回している者は、それを価格表にする価値のあるものにしてくれた連中に金を払え。 これは規範であり、対象は数が少なく、しかも名指しできる。全員が開発者に売っており、全員が開発者にどう見られるかを気にしている。法律も財団も助成委員会も要らず、どの企業も自分が寛大だと感じる必要もない。必要なのは、レジストリとミラーを運営する側が、それらの企業がすでに支払っている請求書に一行足し、定期ジョブを一つ回すことだけだ。三十年かけて試してきた他のすべては、オープンソースを消費する一万社へのお願いだった。これは、オープンソースを供給する十二社への指令だ。