オープンソース経済学：「コード」ではなく「供給」をメーターして支払う新均衡

2013 年、オープンソース経済学に関するブログ投稿を書こうと意欲を持った以来、この問題は長年にわたり議論されてきました。現在のベストな試みは 2022 年の iOS メモで、「何もうまくいかない」という結論に至ったものですが、5,000 語の文章を書くには不十分だと判断され、さらに 4 年間放置されました。今、ようやくアイデアが浮かんできました。ただし、これを現実のものにするには膨大な作業が必要です。

本稿では、オープンソースモデルの真の均衡、「フリーとクローズド」の関係性、そして**「レジストリレイヤー」**においてこそ実現可能な解決策について論じます。

オープンソースは「進化的安定戦略（ESS）」である

オープンソースは安定した結果を有するゲームであり、その結果は**「フリーの勝利」**です。

以前、進化生物学から着想を得た「鷹と鳩」のモデルを考えました。

• 鷹: 資源をめぐる競争で争う存在。
• 鳩: 資源を共有し協力的な存在。

すべての集団が鷹ばかりだと不安定（全員負傷）、すべてが鳩ばかりでも不安定（単一頭の鷹が支配）です。安定しているのは、どちらも利益が得られないようなバランスの取れた混合状態です。これを「進化的安定戦略（ESS）」と呼びます。

ソフトウェア世界においてこの枠組みを適用すると：

• クローズドソースは鷹：コードを秘匿し、プレミアムを支払わせようと闘争する。
• オープンソースは鳩：コードを無料公開し、他者の貢献も利益も共有する。

彼らが競い合う究極の資源は「お金」ですが、それはまず利用者や開発者の注力として現れます。

我々が到達した均衡の特異性

ソフトウェア片の進化的安定戦略とは：

**「誰でもこれを商用を含めて何にでも無料で利用できるようにする」**こと

MIT ライセンスや Apache ライセンスといった「何も要求しないライセンス」がそれです。少しだけ寛容な鳩になろうとして試みた全てのプロジェクトは、フルな鳩（完全なオープンソース）のまま続けたプロジェクトに敗北しました。

歴史的事例：寛容なライセンスの失敗

BSD+Patents

ライセンスでお金を請求しようとした者一人として、能力のあるフォークに対して立ち往生した者はいません。これはイデオロギーによるものではなく、市場の構造（破壊的革新）の問題です。フリーはシェアを勝ち取り、クローズドは利潤を勝ち取り、両者はともに勝利します。

問題点：燃え尽きとバランスト・コスト

安定した結果は、人々の燃え尽きていくことの上に成り立っています。現状では「フリーが勝ち、クローズドがお金を稼ぎ、全員が居場所を持つ」というバランスは機能しています。問題は、「無料の層」から内側を見たときです。

オープンソースメンテナーの実情（Tidelift 2024 年調査）

• 報酬なし: メンテナーの 60% は無報酬。
  • （前年の調査でも同様の結果）
• 孤独な労働: 無報酬者のうち 61% が一人で働いている。
• 退去意欲: ほぼ全てのメンテナーの約 60% が退職または退職を考えている。
  • 理由：生活がある、関心が失われた、燃え尽きたため。

システム全体の負荷

• Sonatype (2023 年調査): オープンソースプロジェクト 120 万のうち、積極的にメンテナンスされているのは 11% に過ぎない。
• Linux Foundation Census II: 最も使用される 50 パッケージのうち、コードの 80% を 136 人の開発者が書いている。
• Harvard の推計: オープンソースが崩壊した場合、それを代替するために企業は 8.8 兆ドルを費やす必要がある。その価値の 96% はわずか 5% の開発者が生み出している。

JavaScript エコシステム全体像: 膨大な数の微小なパッケージがあり、各パッケージには一人またはそれ未満の開発者がいる。企業がビジネスを賭けている依存関係ツリーの下に位置しています。

xz バックドア事件の教訓

2024 年、地球上のほぼ全ての Linux マシンで圧縮ライブラリにバックドアが発見されました。

• 原因: 非常に忍耐強く社会的操作を施した偽の貢献者が、報酬を受けていない唯一のメンテナーから鍵を受け渡すように誘導。
• 発見: SSH が遅く見えることに気づいた Microsoft エンジニアが偶然発見（望まない防御）。
• 現状: メンテナーは公に苦労しており追いつけていない。支援する代わりに誰かが彼を甘えさせた。

「システムが壊れている」のは誤り

システム自体は壊れていません。私たちが共同で耐え忍ぶことに決めたレベルの人的コストにおいて安定しています。メンテナーが燃え尽き、別の誰かが引き継ぎ、再び燃え尽きる。この連続的な状態こそが均衡です。これは血によって動く機械であり、進化的安定戦略であるため、我々はそれを簡単には変える力を持っていません。

変わったのは速度のみです。

• Linux の場合：コアのメンテナンスは夜や週末で十分でした（誰も待っておらず）。
• Web/ npm の時代：約 10 年間で 100 万の微小なモジュールが出現。それぞれが数週間で誰かの生産システムを支えるものになる可能性を持つ。
• セキュリティも加速：人気のライブラリバグは数日で悪用され、数万企業に影響を与える。

開発者は歌手が歌うようにソフトウェアを書く：誰も聴いていなくても書く。これを修正すべき問題ではなく、全体システムを機能させる要素と捉えるべきです。

既存の解決策の限界

私たちが試みている全ては資金の流れを変え、均衡自体を変えるものではありません。悲しい部分ですが、四年間避けてきた現実があります。

試行錯誤されたアプローチ

1. 寄付（チップ）: GitHub Sponsors は総額 1 億ドルを越えたが、権力法則に従い数名の有名人が成功するだけで、中間層は昼飯代しか手取りない。
2. 財団: Linux Foundation, Apache など。しかし、メンテナーから財団への収益は 3% に過ぎず（政府からは 1%）。財団は船を操るための企業であり、漕ぐ人々を支給する企業ではない。
3. 企業の寛大さ: Google Open Source Office や Sentry の Pledge など。慈善として機能するが、兆単位まで拡張できない。
4. 有料セキュリティ（Tidelift）: 良いアイデアだが、独自に十分な購入者を見つけることができない行方となった例もある。
5. 政府資金: ドイツの主権テックファンドは素晴らしいが、一つの基金であり、EU 全体でのバージョンも提案段階。
6. Mozilla: Google の検索収益から資金化されており、他の収益源への依存に陥っている。
7. ライセンス戦略: 二重ライセンスやソースアベイラブルなど、「鷹になろうとする鳩」は、フルな鳩に敗北する。

共通の問題：任意性（ボランティア）

• 企業にお金を払うよう頼まれ、一部は支払うが大半は支払わない。
• 慈善は規模化せず、誰にも命令権限がない。
• 30 年間企業に支払いを求めてきましたが、完全なテスト対象と見なすことができます。

結論：企業は確かにオープンソースにお金を払っていますが、それをコードを書く人々に支払わないだけです。

新しい視点：「供給ゲーム」での勝利

企業がすでに開いているお金を無駄にする前に、視点を改める必要があります。 フリーはコードゲームで勝ちますが、デフォルトは供給ゲームで勝ります。

なぜ ESS がここでは適用されないのか？

コードゲームでは資源はソフトウェア自体であり、フリーが毎回勝ちます（誰でもコピーできる）。しかし、供給ゲームでは資源は「コードの来処を考えずに済むこと」です。このゲームはデフォルトが何であるかで決まります。

• レジストリのフォーク失敗: npm, PyPI, Docker Hub の無料ミラーは存在するが、企業は JFrog などに年間 5 億ドルを支払うことをやめない。
• Docker の例:
  • 2020 年 11 月：匿名プルをレート制限。
  • 2021 年 8 月：企業向け有料化（Podman 等の無料代替品が存在しながら）。
  • 結果：収益は 2020 年の約 1,200 万ドルから 2024 年には 2.07 億ドルへと増加。

レジストリ是整个システムにおいて二つのゲームが触れる唯一の場所です。

• ここが無料コードが供給に変わる場所であるため、ライセンスとは異なりコピーによって迂回できない（法的制限ではなく、極めて便利なインフラストラクチャ）。
• 迂回したくありません。迂回するのは代金を支払っても痛みのあることです。

誰もレジストリレイヤーで本格的に試みていません。

既存の試み（Flossbank, Ruby Together など）は失敗しました。彼らは「任意性」に頼り、非任意性のもの（Docker のような強制力）だけが成功して金を保持しました。ドメインを所有する者は未だに企業から供給に対して課金し、供給を作る人々に価値を支払いませんでした。

提案：レジストリレイヤーでのメーターとロイヤルティ

以下の 3 つの部分で構成された新しいモデルです。どれも新しいものではありませんが、それらを同じ場所に置く（実施する）ことが新しさです。

1. レジストリのメーター化と課金

• 原理: レジストリは企業の使用をメーターし、その使用に対して課金する。
• 現状の適用: npm, PyPI, Docker Hub, Maven Central は既にレート制限やエンタープライズティアを持っており、ミラーベンダーはシート単位で請求している。
• モデル: Docker のルールが正しい。個人・小チームは無料で、あるサイズ以上の企業はサブスクリプション（調達部門がサインするレベル）を持ちます。

2. ロイヤルティの自動分配

• 原理: その収益の一部をロイヤルティとし、パッケージへ直接送金する。
• 方法: レジストリや財団ではなく、支払う顧客の依存関係ツリーに表示される全てのパッケージへ、自動的に毎月分配する（式典なし、ありがとうメールなし）。
• 意義: お金は片方の端から入って別の端から出なければならない。データベース一つで解決できること（thanks.dev や過去の Flossbank の実装例）。

3. ドメイン所有者の実行責任

• 主体: これを行うのはドメインを所有する者（約 12 のレジストリ）。
• 利点: メンテナーは既に興味を持つ一つのレジストリにアカウントを持っており、支払い方法はフォームフィールド一つで管理できる。
• 対象: 請求側は数千の大きな企業であり、その多くは既にサプライチェーン上の誰かの顧客である。発見と受領の問題は解決済み。

イザック・シュルター（npm 創設者）の視点

「サポートではなくアクセスに対して課金すべきだ」

これは利殖企業であればコードを支払うことなく得られないという論理です。料金の位置を移動させることが鍵です：

• ライセンスに置くとフォークされる。
• レジストリに置くと JFrog のような収益を得る。
• GitHub は npm と GitHub Sponsors を所有しており、npm のエンタープライズ顧客のために切り替え可能。

よくある質問への回答

「企業が無料ミラーに移り変わらないでしょうか？」

移る企業もありますが、Docker の場合と同じ理由で問題にはなりません。自身のミラーを実行する余裕がある企業は今日既に無料でできています（JFrog に支払い続ける理由は「必要なものを不要にしているから」）。離脱する顧客はフリーライドしており、Docker はミラーからの失っても収益は 15 倍に増加しました。

「これは単なる Tidelift の繰り返しではありませんか？」

いいえ。違いが重要です。

• Tidelift は独立した購入決定（新しいベンダー、予算の新しい行）。
• ミラー請求書のロイヤルティは決断そのものではありません。調達の誰一人としてそれは一つの決定として見ることすらありません。
• Tidelift は企業が「尋ねられたレイヤーでのみ」支払いを示しました。

「人々はそれをゲーム化しませんか？」

はい、Spotify モデルと同様のリスクがあります（ストリームごとに支払えばストリーミングファームを構築し、千個のジャンクパッケージを公開する）。しかし、支払う顧客の依存関係ツリーにおける存在で単純なダウンロードではなく重み付けすることで、これらの問題を回避します。

結論：なぜこれが機能するか？

私がこれが機能すると考える理由は、均衡の変化を求めないことです。

• ライセンスは変わらないのでフォークされず、「オープンソース」の定義議論も不要。
• 慈善でも命令でもない。誰一人として与えるよう求められず、最も無謀な企業も無視する法律によって支払うよう命じられることもない。
• 企業が既に供給に対して支払い続けており、請求書に新しい行が増えるだけ。

ロングテイルを支払う

チップは有名人を支払い、財団はスタッフを支払い、政府資金はクリティカルリストの 20 プロジェクトを支払いますが、依存関係ツリーのロイヤルティは「奇数（is-odd）」を支払います。

• 小さいしかし有用なものを書いた人が四百企業の生産システムに入った場合は、四百個の小さな寄与を得ます。
• 申請せず、マーケティングせず、ブランド化することなく。

多くのオープンソース持続可能性の議論が腐って「メンテナーにビジネススキルを向上させるよう言及」するようになりましたが、それは完全に逆です。メカニズムは人々が有用であることに対して支払い、良い質問をする能力に対して支払うべきです。

LLM と加速

2022 年以来変わったもう一つは、ソフトウェア作成のコストが急激に低下したことです。安いソフトウェアとはつまり多くのソフトウェアであり、ロングテイルは長くなり、依存関係ツリーに入るパッケージの数は増え減りません。また AI エージェントが最も急速に成長するオープンソース消費者であり、レジストリを通じて消費しています。

LLM はこれを緊急にし、より価値あるものにします。コードは作成しやすくなり、供給を保証するコストが増大しています。これは供給層を支払う価値がある条件であり、誰が支払われるべきかを決める正確な瞬間です。

最後の言葉

オープンソース開発者は無力と描かれ、無視できる散らかったボランティアの山ですが、記録は異なります。Facebook を React のライセンス変更させたり、Redis（数億ドル企業）を戦略的決定で逆転させたりしてきました。協調的な拒否が機能し、鳩は脱退者を罰することにとても長けています。

30 年間目標はコードにお金を請求しようとした企業でしたが、その間に企業がお金を使うオープンソースの流れは十二のベンダーがチョークポイントに座り込んでいました。規則を破っていないためであり、規則がないためです。これは全体の問題です。

メーターを運転する人々が、計測する価値のあるものを製造する人々を支払う。 それは少数の指名されたターゲットを持つ規範であり、全員が開発者に販売し、開発者の意見に関心を持ちます。レジストリとミラーベンダーが既に企業に支払っている請求書に新しい行を追加し、cron ジョブを実行する必要があります。三十年間試みている他の全ては一万社のオープンソースを消費する企業への訴求でした。これは十二の供給者への指示です。