オープンソースインフラにもビジネスモデルが必要な理由：持続可能な開発のために

この記事は Dries Buytaert 氏の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。

オープンソースのインフラは不可欠な存在でありながら、目に見えにくく、慢性的に資金不足です。より持続可能なアプローチとして、インフラの運営コストをそれに最も依存している組織と結びつけることが考えられます。

オープンソースソフトウェアはダウンロードこそ無料です。しかし、それを使えるようにしているインフラは無料ではありません。

開発者がnpm・Composer・pip・Cargoを通じて依存パッケージをインストールしたりアップデートしたりする際、これらのツールは何百万ものソフトウェアパッケージをホストして配布するパッケージレジストリに依存しています。メンテナーが共同作業をする際にも、Gitリポジトリ・CIパイプライン・ソフトウェアのビルド・テスト・リリースを行うための各種ホスティングサービスに頼っています。

こうしたインフラのほとんどはエンドユーザーの目に触れることがなく、その運営コストを気にする人はほぼいません。

しかし、無料というわけではありません。サーバーを運用し、帯域幅のコストを払い、サポートの問い合わせに対応し、セキュリティ上の問題を修正し、全体を安定稼働させる人間が必ずいます。

現代のソフトウェアエコシステムの多くは、これらのサービスが安定して機能することに依存しています。それにもかかわらず、運営組織はほぼ常に資金繰りに追われています。

脆弱な取り決めのつぎはぎ

大規模なオープンソースプロジェクトはいずれも、なんとかインフラを維持する方法を見つけてきました。多くの場合、それは寄付されたサービス・スポンサーシップ・資金調達・クロスサブシディ・特定企業の支援など、いくつかの組み合わせです。

下の表は各オープンソースプロジェクトが主に依存している資金調達の仕組みを示しています。ほとんどのプロジェクトは複数の方法を組み合わせて運営しています。

エコシステムによって組み合わせは異なり、複数の仕組みを同時に活用しているプロジェクトもあります。しかし一つ際立っていることがあります。いずれのアプローチも、インフラの利用量に直結した資金調達にはなっていないのです。

PythonパッケージインデックスのPyPIは、スポンサーシップモデルの典型例です。Fastly・AWS・Google Cloudが提供するインフラ上で、1日に数十億件ものダウンロードを処理しています。Python Software Foundationは昨年10月の投稿でこの構造の脆弱性を率直に説明しました。スポンサーが1社でも更新をやめれば、失われたインフラを補うために月数万ドルのコストが発生するというのです。

PHPの主要パッケージリポジトリであるPackagistは異なるアプローチを採っています。Private Packagistという商用製品も販売している民間企業が運営しており、有料製品の収益が無償の公開レジストリを支えています。比較的持続可能なモデルのひとつですが、公共財が特定の一企業の成否に依存しているという側面もあります。

npmは独立した企業として運営しようとしましたが深刻な財政難に陥り、2020年にGitHubに買収されました。結果として、JavaScriptの重要なインフラがMicrosoftの傘下に入ることになりました。

WordPress.orgは同様の構図の別バージョン、つまり企業による支援で動いています。エコシステム最大の商業的受益者であるAutomatticが、ほとんどのインフラコストを負担しています。機能はしていますが、インフラの資金を出す側がそれを管理するという構造でもあります。

Linux Foundationが支援するフェデレーション型パッケージマネージャーFAIRプロジェクトは、WordPressエコシステムに独立した選択肢を提供しようと設計されました。ソフトウェアは完成しましたが、運営者は長期的な資金調達の確約を得られず、最近撤退を余儀なくされました。

RubyGemsはコミュニティ資金調達の道を選び、昨年レジストリの運営費を賄うために約110社のサポーターを目標として、企業に年間2,500〜5,000ドルの支援を求めるプログラムを立ち上げました。

私がリードに携わるオープンソースCMSのDrupalは、Drupal AssociationがプロジェクトのインフラのConoserverを担っています。Composerエンドポイント・GitLabリポジトリ・CIパイプライン・自動更新通知などの運営には年間約300万ドルのコストがかかります。資金は、インフラの寄付・コミュニティ資金調達・DrupalConの収益・スポンサーシップの組み合わせで賄っています。

経済的な基盤が崩れると、その影響は目に見えるかたちで現れます。2026年2月、GNOMEは帯域幅コスト削減のために自前のGitLabからGitHubミラーへとGitトラフィックをリダイレクトし始めました。その結果、GNOMEの帯域幅コストの一部がGitHubとその親会社であるMicrosoftに吸収されることになりました。

これらの事例が総じて示しているのは、同じ根本的な問題です。ほとんどのオープンソースインフラには、真のビジネスモデルがありません。提供する価値に見合った収益ではなく、寄付・企業スポンサー・コミュニティの資金調達によって何とか生き延びているのです。

管理者からサービスプロバイダーへ

私が理にかなっていると思う方向性のひとつは、シンプルな価値の交換です。個人や小規模プロジェクト向けにコアインフラを無償提供しつつ、規模を拡大して利用している組織には、自分たちのソフトウェアが依存しているインフラのコストを負担してもらう。寄付としてではなく、インフラの利用に対する対価として。

オープンソースプロジェクトのインフラに課金するという考えに、本能的に反発する人もいるでしょう。有償コントリビューターについての初期の議論を覚えている方には、その感覚が懐かしく感じられるかもしれません。当時、企業資本がボランティアを追い出すと懸念する声が多くありました。しかし実際には逆のことが起きました。プロジェクトは成長し、コントリビューターの基盤は広がり、有償エンジニアは最も活発なコントリビューターの一部になりました。

だからといって、新しい資金調達のアイデアがすべて良いわけではありません。しかし、本能的な違和感だけを理由に却下するべきでもないのです。

オープンソースでは、公平に見えるものが実際には公平でないことがあります。「全員に無料」は平等に聞こえますが、コストが消えるわけではありません。それは最も余裕のない人々に転嫁され、最も恩恵を受けている組織が最も少ししか払わない、という構造になりがちです。Fortune 500企業がオープンソースのインフラを無料で使い続けるとしたら、それは中立な結果ではありません。間違った方向への補助金です。

コストと利用が切り離されていることが問題なら、出発点はそれをつなぐことです。具体的にどう実現するかは別の設計上の問題であり、オープンソースプロジェクトごとに答えは異なるでしょう。ひとつの可能性として、ダウンロード数やAPI利用量に応じた段階的な利用量課金が考えられます。測定方法・閾値・実施方法については、コミュニティでの丁寧な議論が必要です。

ガバナンスは資金調達の後についてくる

インフラの資金調達モデルを変える必要があるなら、誰が決めるのかという問題が生じます。オープンソースにおいて、こうした問いは最終的にコミュニティに属しています。

しかし、コミュニティは真空の中でこれらを決めるわけではありません。実際には、ガバナンスは資金調達に従う傾向があります。

オープンソースのインフラをめぐる議論は、しばしばガバナンスに焦点を当てます。誰がコントロールすべきか、誰が決定権を持つべきか、という問いです。しかし現実には、それはより単純なもの——誰が費用を払っているか——によってほぼ決まってしまいます。

FAIRはその最近の例です。フェデレーションという発想が間違っていたから失敗したわけではありません。代替手段として資金を調達するに足るビジネスケースを誰も構築できなかったから失敗したのです。

ひとつの組織がインフラの費用を負担すれば、最終的にはその組織がインフラを支配します。より広いステークホルダーが資金を出せば、ガバナンスもそれに伴って広がります。

だからこそ、オープンソースのインフラに必要なのは、より良い資金調達活動だけではありません。共有インフラの運営コストを、それに最も依存している組織と結びつけるビジネスモデルが必要なのです。

エコシステム全体が依存するインフラが、いつまでも善意だけに頼り続けることはできません。ビジネスモデルを持つに値するのです。

資金調達の問題を解決することが、ガバナンスの問題を解決するための前提条件です。

草稿を査読してくれたTiffany Farriss、Tim Lehnen、Gábor Hojtsy、Lauri Timmaneeに感謝します。

By Dries Buytaert

PS: LinkedInでも議論が続いています。

この記事は「Open Source infrastructure deserves a business model」(投稿日：2026-03-09)の翻訳記事です。