オープンソースはリーダーを失うとどうなるか

ライアン・ダールがNode.jsから身を引いたとき、プロジェクトは生き延びたが、安定するまでにはガバナンスの再構築、フォーク（io.js）、そして和解と、長い年月が必要だった。グイド・ヴァン・ロッサムがPythonのBDFL（「終身の慈悲深い独裁者」）を辞任したときも、コミュニティは数か月にわたってガバナンスモデルを議論し、最終的にステアリング評議会の設置に落ち着いた。Denoプロジェクトが自らのリーダーシップをめぐる問題に直面したときは、そのランタイムに賭けていたすべての開発者に余波が及んだ。

これらは孤立した事例ではない。オープンソース開発に構造的に組み込まれた特徴だ。重要なオープンソースプロジェクトの多くは、ごく少数の人、しばしば一人に依存しており、その度合いはユーザーが思っている以上に大きい。その人が離脱したり、燃え尽きたり、優先順位を変えたり、物議を醸す決定を下したりすると、プロジェクトは実存的な危機に直面するが、GitHubのスター数をいくら集めてもそれは防げない。

バスファクター問題

「バスファクター」、つまりプロジェクトが崩壊するまでに何人がバスにはねられる必要があるかという指標は、多くのオープンソースプロジェクトで恐ろしいほど低い。2015年の調査では、npmパッケージの60%超が単一のメンテナーしかいないことがわかった。より最近の重要なオープンソース基盤の分析では、数百万の下流依存を抱えるプロジェクトが、一人か二人の無償の趣味的な作業によって維持されていることが多いと判明している。

仮想の話ではない。インターネットの暗号化通信の大部分を守っていたOpenSSLは、Heartbleedが発見された当時、主に二人が空いた時間で保守していた。11行の単純なnpmパッケージであるleft-padは、作者が削除した際に数千のビルドを壊した。週に2500万回以上ダウンロードされるcore-jsは、「食べていくのがやっとだ」と公言している一人の開発者が保守している。

パターンは一貫している。重要なプロジェクトは情熱的な個人によって始まり、採用が広がり、数百万人が依存するインフラになる。それでも保守の負担は同じ一人か二人に残る。プロジェクトの重要性は指数関数的に膨らむが、支えは増えない。

ガバナンスモデルとそのトレードオフ

オープンソースプロジェクトのガバナンスには、いくつかの異なる方式があり、それぞれ強みと典型的な失敗パターンがある。

BDFLモデル

一人の人物が最終決定を下す方式だ。Python（グイド・ヴァン・ロッサム）、Linux（リーナス・トーバルズ）、Ruby（まつもとゆきひろ）など、成功したプロジェクトには、そのセンスと判断でプロジェクトを形づくる強力な技術リーダーがいることが多い。利点は明確な方向性、一貫したビジョン、速い意思決定だ。BDFLは合わない機能に「no」と言えるので、プロジェクトは焦点を保てる。

失敗パターンも同じくらい明確だ。BDFLが去って後継者計画がない場合である。Pythonはグイドが数十年かけてコミュニティを育ててきたにもかかわらず、彼の辞任後の移行は順調ではなかった。コミュニティの関与が薄いプロジェクトでは、BDFLが去ると単に消えてしまうことも多い。

財団モデル

Apache、Eclipse、Linux Foundationなどは、非営利財団の下で正式なガバナンス構造を持つ。技術運営委員会、コミッター選挙、意思決定プロセスなどだ。これにより組織としての継続性が生まれ、構造が残るため、個人が抜けてもプロジェクトは存続する。

トレードオフは官僚主義と政治力学だ。財団のガバナンスは遅く、争いが起きやすく、企業の利害に取り込まれることもある。BDFL主導のプロジェクトの機動力と比べて、委員会プロセスを窮屈に感じる開発者もいる。最悪のケースは、ガバナンスが技術的な優劣よりも組織の政治の話になってしまった財団だ。

企業スポンサーモデル

React（Meta）、Go（Google）、Rust（当初はMozilla、現在は独自の財団）、TypeScript（Microsoft）など、多くの主要プロジェクトは、中核メンテナーを雇用する企業にスポンサーされている。これは資金問題を解決する。メンテナーは報酬を得てフルタイムで働けるし、プロジェクトは企業のエンジニアリング資源の恩恵を受けられる。

リスクは利害の一致だ。企業の優先順位は変わる。MozillaはRustチームを解雇した。Googleもビジネス上の焦点が移ると、オープンソースプロジェクトの優先度を下げ、資金を絞ってきた。企業の戦略的利益がプロジェクトのコミュニティの利益から離れると、摩擦は避けられない。最近、企業スポンサーによってプロジェクトのライセンスが変更される動き（Redis、Terraform、Elastic）は、このモデルがいかに脆いかを示している。

健全なフォークとは

フォーク、つまりプロジェクトの競合する複製を作ることは、しばしば失敗の兆候とみなされる。しかしオープンソースにおいては、これは究極の安全弁だ。リーダーシップが機能しなくなったとき、フォークによってコミュニティは元のメンテナーに頼らずに活動を続けられる。

Node.jsのio.jsフォークは、Nodeをよりオープンなガバナンスモデルと高速なリリースサイクルへと向かわせた。プロジェクトが統合されたとき、Nodeはその恩恵を受けた。LibreOfficeはOpenOffice.orgからフォークし、衰退していたSun/Oracleの関心からプロジェクトを救った。MySQLがOracleに買収された後にフォークされたMariaDBは、コミュニティ主導の代替として存続している。

最近では、ライセンス変更が生産的なフォークを生んでいる。ElasticがElasticsearchのライセンスを変更すると、AmazonはOpenSearchとしてフォークした。HashiCorpがTerraformのライセンスを変更すると、コミュニティはLinux Foundationの下でOpenTofuとしてフォークした。これらのフォークが存在するのは、フォークする権利こそがプロジェクトのリーダーシップに対するコミュニティの究極のチェックだからだ。

フォークがうまくいくのは、コードだけでなくコミュニティがきれいに分かれたときだ。アクティブなメンテナーとコミュニティの支持を得たフォークは成功する。誰もついていかない、不満を抱えた一人の開発者によるフォークは、混乱を生むだけだ。

燃え尽きのスパイラル

オープンソースのリーダーシップ危機の多くは、劇的な離脱から始まるわけではない。始まりは燃え尽きだ。課題、プルリクエスト、機能要望、権利意識の強いユーザーの重みで、メンテナーの能力と熱意が少しずつ削られていく。

その流れは予測可能だ。メンテナーが便利なものを作る。ユーザーが集まる。バグ報告、機能要望、サポートの質問、そして要求がついてくる。責任感からメンテナーはすべてに応えようとする。量が能力を超える。通知を見るのが怖くなる。返信は遅くなり、そっけなくなり、やがて途絶える。最終的に彼らは姿を消し、プロジェクトは「ゾンビ保守」の時期に入る。技術的には生きているが、実際には放棄されている状態だ。

オープンソースのメンテナーの燃え尽きは個人の欠陥ではない。構造的な問題だ。プロジェクトは有限の人数の時間と注意に対して無制限の需要を生み出すが、その需要を管理する仕組みは組み込まれていない。

対処法を見つけたメンテナーもいる。返信時間の厳格な線引き、トリアージのコミュニティメンバーへの委任、GitHub SponsorsやOpen Collectiveを通じた有償の保守、あるいは単に返信が遅いことを受け入れることなどだ。しかしこれらには、常に連絡可能であれという圧力に意識的に抗う必要があり、それは多くのオープンソースコミュニティの文化に逆らうことになる。

健全な後継とはどういうものか

リーダーシップの交代をうまく行ったプロジェクトはいくつかあり、共通のパターンがある。

コードだけでなく知識も分散させる。 プロジェクトの「部族的知識」、つまりなぜ特定の決定が下されたのか、どんな代替案が検討されたのか、設計原則は何かといったことが、一人の頭の中だけでなく文書化されている。Architecture Decision Records（ADR）や詳細なRFCがこの役割を果たす。
コミット権とリリース権限を複数の人が持つ。 リリースを切れるのが一人だけなら、その人が単一障害点になる。健全なプロジェクトには、独立して新しいバージョンをリリースできる人が少なくとも3〜5人いる。
明文化されたガバナンス文書。 意思決定はどう行われるか。誰が何に権限を持つか。新しいメンテナーはどう加わるか。危機の前にこうした問いに答えを出しているプロジェクトは、場当たりで対応するプロジェクトより後継がうまくいく。
突然の離脱ではなく段階的な移行。 最良のリーダー交代は、退任するリーダーが数か月かけて意図的に関与を減らし、後継者を指導し、権限を明示的に移譲するときに起きる。善意であっても、突然の離脱は空白を生む。
財政的な持続可能性。 信頼できる資金源（財団、企業スポンサー、コミュニティ資金）があるプロジェクトは、後任のメンテナーに時間の対価を支払えるため、交代を乗り切りやすい。無償のフルタイムの仕事を引き継いでくれと頼むのは、難しい相談だ。

ユーザーと企業がすべきこと

ビジネスがオープンソースソフトウェアに依存しているなら（そして実際そうだ）、依存しているプロジェクトの健全性はあなたの利害に関わる。実践的なステップをいくつか挙げる。

依存関係のバスファクターを監査する。 スタックで重要なオープンソースプロジェクトを見てみよう。アクティブなメンテナーは何人いるか。最後のリリースはいつか。セキュリティの問題にどれくらい速く対応しているか。メンテナーが一人で、半年前のセキュリティ脆弱性が放置されているプロジェクトは、知っておくべきリスクだ。
使っているものに資金を出す。 プロジェクトがビジネスにとって重要なら、その資金提供に貢献しよう。GitHub Sponsors、Open Collective、Tideliftがその仕組みを提供している。メンテナーへの資金提供のコストは、重要な依存関係がメンテナンスされなくなるコストに比べれば微々たるものだ。
上流に貢献する。 バグ修正、ドキュメントの改善、課題のトリアージ。これらはメンテナーの負担を減らし、チームがコードベースに慣れる助けにもなる。プロジェクトが新しいメンテナーを必要とするときには、あなたがその役割を引き受けられる立場になっている。
代替案を用意しておく。 重要な依存関係については、プロジェクトが放棄されたら何をするかを考えておこう。フォークして自分たちで保守できるか。移行先の代替手段はあるか。これらの問いに答える時期は、答えが必要になる前だ。

オープンソースのガバナンスは華やかな仕事ではない。見出しになることも、GitHubのスターを集めることもない。しかし創設者が去った後も生き残るプロジェクトと、そうでないプロジェクトの違いは、ほぼ常にガバナンス、つまり決定を文書化し、権限を分散し、後継を計画するという地味で構造的な作業にある。長く続くプロジェクトは、ソフトウェアだけでなく制度を築いているのだ。