2024年3月、圧縮ライブラリ XZ Utils にバックドア（CVE-2024-3094）が発見された。犯行は約3年にわたるソーシャルエンジニアリングであり、発覚が遅れていれば「世界中の数億台のコンピュータへのマスターキー」（元Facebook CSO アレックス・スタモス）となるところであった。このインシデントは、オープンソースソフトウェア（OSS）の持続可能性という構造的問題を白日の下に晒した。2026年1月末、ブリュッセルで開催された FOSDEM 2026 では、バーンアウト、資金モデル、規制対応に関するセッションが相次ぎ、危機感が共有された。本稿では、OSS の「無償の公共財」モデルがなぜ破綻しつつあるのかを分析する。

FOSDEM 2026 ――「焼き尽くされる自由」

2026年1月31日から2月1日にかけて開催された FOSDEM 2026 は、8,000人超の開発者が集まる世界最大級の FOSS カンファレンスである。今回のプログラムは、OSS コミュニティが直面する現実的な圧力に正面から向き合う内容であった。

基調講演「Free as in Burned Out: Who Really Pays for Open Source?」は、無償労働への依存を正面から問い直した。寄付、スポンサーシップ、オープンコアといった既存の資金調達モデルがなぜ不十分であるかを解剖し、「OSS税（Open Source tax）」の導入可能性にまで言及した。

心理学研究者ミランダ・ヒースは「Burnout in Open Source: A Structural Problem We Can Fix Together」において、メンテナーの燃え尽きを構造的問題として分析した。学術文献のレビューと開発者への聞き取りに基づき、6つの要因を特定した。(1) 報酬を得ることの困難、(2) 過重な作業量と時間的拘束、(3) 保守作業の無報酬感、(4) 有毒なコミュニティ行動、(5) 過剰な責任感、(6) 自己証明への圧力、である。構造的改善策として、OSS 開発者への報酬支払い、承認と尊重の文化の醸成、コミュニティの拡大、メンテナーのためのアドボカシーが提言された。

ルース・スーレは「Building on Success: Sustainability of Open Source」で、「オープンソースは自らの成功に苦しんでいる」と指摘した。約30年にわたり問題を解決してきたコミュニティが日常生活に不可欠なソフトウェアの基盤となった今、「最初の数十年を支えた方法論では、今後のオープンソースを維持できない」と警鐘を鳴らした。

XZ Utilsの教訓 ―― 単独メンテナーの脆弱性

XZ Utils 事件は、OSS 持続可能性危機の象徴的事例である。唯一のメンテナーであったラッセ・コリンは、長年にわたり単独でプロジェクトを維持してきた。2021年11月頃から「Jia Tan」を名乗るアカウントがコミュニティに参入し、ソックパペット（自作自演アカウント）による圧力を通じてコリンに共同メンテナー権限の委譲を迫った。約3年にわたる信頼構築の末、Jia Tan はバージョン 5.6.0 および 5.6.1 にバックドアを挿入した。このバックドアは liblzma ライブラリを介して OpenSSH サーバに作用し、特定の秘密鍵を持つ攻撃者にリモートコード実行を許すものであった。CVSS スコアは最高値の 10.0 が付与された。

発見は偶然に近い形でなされた。マイクロソフト所属の PostgreSQL 開発者アンドレス・フロイントが、SSH 接続時の異常な CPU 使用率を調査する過程で不正コードに気づいたのである。発覚があと数週間遅れていれば、主要 Linux ディストリビューションの安定版にバックドアが組み込まれ、世界規模のセキュリティ災害となっていた可能性が高い。

事件後、OpenSSFと OpenJS Foundation は共同声明を発表し、「これは孤立したインシデントではない可能性がある」と警告した。メンテナーに対して「友好的だが執拗な」未知のコミュニティメンバーからのメンテナー権限要求に注意するよう呼びかけた。

資金モデルの限界 ―― 寄付・スポンサーシップの不十分さ

Tidelift の調査によれば、OSS メンテナーの60%は一切の報酬を受けておらず、60%が離脱を検討した経験があり、44%がバーンアウトを離脱理由として挙げている。GitHub Sponsors の企業参加数は約4,200社に達したが、オープンソースを利用する企業は世界で約3億社にのぼる。この圧倒的な非対称性は、現行モデルの限界を端的に示している。

2026年1月の議論では、「人々が余暇に無償で重要インフラを保守することを期待する現行モデルは、根本的に破綻している」と断じられた。2025年11月には、Kubernetes の主要コンポーネントである Ingress NGINX が、技術的陳腐化ではなくメンテナーの疲弊を理由にリタイアを宣言した。

FOSDEM 2026 で発表された「The Terrible Economies of Package Registries」は、パッケージレジストリの経済的持続不可能性を示した。Maven Central、PyPI、npm 等は毎月数十億回のダウンロードを処理するが、運営組織の多くは寄付と少数のスポンサーに依存している。さらに AI エージェントによる大量スクレイピングが帯域・計算資源を圧迫し、「OSS は無料」という前提は成り立たなくなっている。

CRAと規制 ―― 無償労働への責任転嫁リスク

2024年12月に発効した EU サイバーレジリエンス法（CRA）は、デジタル製品のサイバーセキュリティ基準を定める規制である。非商業的な OSS 開発者は原則として適用対象外とされるが、新たに導入された「オープンソース・スチュワード」概念により、OSS プロジェクトに組織的支援を提供する法人はサイバーセキュリティポリシーの策定、脆弱性対応、市場監視当局への協力が義務づけられる。

2026年6月にはコンフォーミティ評価機関の届出規定が適用開始され、同年9月までに脆弱性報告義務が発効する。違反時の最大制裁金は1,500万ユーロまたはグローバル年間売上高の2.5%である。問題は、「商業活動」の境界が曖昧な点にある。個人開発者が保守するプロジェクトを他者が販売した場合に、責任が波及する可能性が指摘されている。

OpenSSF は「上流の FOSS 開発者によるアテステーションに依拠するアプローチは、責任圧力と経済的歪みを再導入するリスクがある」と警告した。無償で保守している開発者に、政府水準のセキュリティ対応を求めることの非合理性は広く批判されている。

持続可能なモデルの模索 ―― Apereo型、OSS税、構造的改革

FOSDEM 2026 では、Apereo Foundation の自立型モデルが注目を集めた。「Ecosystems, Not Projects: Rethinking Open Source Foundation Funding」は、個別プロジェクトへの資金提供ではなく、エコシステム全体への投資というパラダイムシフトを提唱した。Apereo モデルでは、ファウンデーションがトレーニング、イベント運営、セキュリティ監査、運用支援などのサービスを提供し、恒常的な資金調達活動に依存しない収益基盤を構築する。

他にも複数のアプローチが模索されている。HeroDevs は2,000万ドル規模のサステナビリティ基金を設立し、Open Source Pledge は企業に対し開発者1人あたり年間最低2,000ドルの拠出を求めている。GitHub は EU に対し3億5,000万ユーロ規模の「Sovereign Tech Fund」を設立し、OSS を「デジタル公共インフラ」として扱うよう提言した。

いずれのモデルも万能ではない。しかし、現行の「善意と寄付に依存する」体制が限界に達していることは、XZ Utils 事件、メンテナーの大量離脱、パッケージレジストリの経済的逼迫が証明している。OSS の持続可能性は、もはやコミュニティ内部の問題ではなく、デジタル社会全体の公共政策課題として認識されるべき段階にある。

FAQ

オープンソースの持続可能性危機とは具体的に何を指すのか？

重要なデジタルインフラを支える OSS プロジェクトの多くが、無報酬の個人メンテナーに依存している状態を指す。メンテナーの60%が無報酬であり、44%がバーンアウトを経験している。XZ Utils 事件のように、単独メンテナーの疲弊がサプライチェーン攻撃の温床となるリスクが顕在化している。

EU のサイバーレジリエンス法（CRA）はオープンソース開発者にどう影響するのか？

非商業的な OSS 開発は原則として適用対象外である。ただし、OSS プロジェクトに組織的支援を提供する法人は「オープンソース・スチュワード」としてセキュリティポリシー策定や脆弱性報告の義務を負う。個人開発者であっても、そのソフトウェアが商業活動の文脈で利用される場合に責任が波及しうるグレーゾーンが存在する。

企業や個人がオープンソースの持続可能性に貢献するには何ができるか？

企業レベルでは、Open Source Pledge への参加（開発者1人あたり年間2,000ドル以上の拠出）、OSPOの設置、従業員の上流貢献に対する業務時間の確保が推奨される。個人レベルでは、依存するプロジェクトへの経済的支援、建設的なコミュニケーション、コードレビューやドキュメント整備といった非コード貢献が有効である。

参考文献