オープンソースの衰退の解剖学：なぜプロジェクトは死ぬのか

現代のソフトウェア・サプライチェーンは、オープンソース・ライブラリという不安定な基盤の上に構築されています。最も依存されているパッケージの多くは、実質的に「死んで」いますが、それでも毎日何百万ものビルド・パイプラインによってインストールされ続けています。プロジェクトが機能はしているものの、メンテナンスが行われなくなっているというこの現象は、開発者や組織にとって静かなリスクを生み出します。

プロジェクトがどのように失敗するかを理解することは、より弾力性のあるソフトウェアを構築するための第一歩です。突然の破滅であれ、緩やかな衰退であれ、オープンソース・プロジェクトの死は、真空状態で起こることはめったにありません。それは通常、ヒューマン・バーンアウト（燃え尽き症候群）からリリース・パイプラインにおける構造的な失敗に至るまで、特定の圧力の集合体の結果です。

メンテナーが消えるとき

プロジェクトが死ぬ最も一般的な原因は、コードの背後にいる人間の単純な消失です。これは、いくつかの異なる形で現れます：

• Ghost Maintainers: メンテナーが単に別の場所へ移ります。Issueが積み上がり、repoはアーカイブされずに残るため、沈黙が明白になるまで、健全なプロジェクトと区別がつかなくなります。
• Corporate Orphans: 企業がツールをオープンソース化しますが、ピボット（事業転換）やレイオフによってチームが消滅します。GitHub organizationは存続しますが、組織的な知識が消失し、多くの場合、プロジェクトは非推奨（deprecation）の通知すら出さずに放置されます。
• Thesis Orphans: 研究用ソフトウェアによく見られるケースで、学位取得のために構築されたプロジェクトです。学生が卒業すると、研究室が名目上はrepoを所有していますが、ソフトウェアのメンテナンスは引用数（citations）に寄与しないため、コードは腐敗していきます。
• Funding Cliffs: 助成金によって支えられているプロジェクトは、資金が尽きた瞬間に崩壊することがよくあります。メンテナーは有給の仕事に戻り、フルタイムの努力を必要としていたプロジェクトは「夜間や週末」の作業へと縮小され、実質的にゼロに等しくなります。
• Hired Away: Appleのような企業での雇用契約（common）は、外部でのオープンソース活動を禁じている場合があり、メンテナーが一夜にして沈黙することを余儀なくされることがあります。

「生ける屍」：留まり続けるメンテナー

すべての死んだプロジェクトが沈黙しているわけではありません。活動の形跡を装うことができ、それはゴースト・レポのように誤解を招くことがあります。

• The Burnout Plateau: メンテナーはタイポの修正や依存関係の更新（dependency bumps）は行いますが、設計上の決定や複雑なデバッグは避けます。プロジェクトはフォーク（fork）を阻害するほどには活動的ですが、進化させるには停滞している状態です。
• Benevolent Zombies: 貢献（contribution）グラフが真っ緑（solid green）ですが、すべてのコミットはボットによるものです。Dependabotや自動リリース・エージェントが、何年も人間がコードを読まなくても、最新性に基づいたメトリクスによってプロジェクトを「健全」に保っています。
• Toxic Gatekeeping: 敵対的なメンテナーが潜在的な貢献者を追い払います。コミット数で見ればプロジェクトは健全に見えますが、メンテナーが後継者となる可能性のある人物を組織的に疎外しているため、「バス・ファクター（bus factor）」は1のままです。
• Tribal Knowledge Loss: コードは動作しますが、元の作者が（コア・アルゴリズムを理解していた唯一の人物として）いなくなってしまいます。構造的な変更はリスクが高すぎると判断されるため、プロジェクトはリード・オンリー（read-only）になります。

サボタージュ、乗っ取り、および不可抗力

一部のプロジェクトは衰退するのではなく、積極的に破壊されたり、乗っ取られたりします。

• Captured Maintainers: 悪意のあるアクターがソーシャル・エンジニアリングを用いて公開権限を奪います。xzのバックドアは、これの洗練されたバージョンでした。event-streamの事件は、パッケージを「ボランティア」に譲渡し、そのボランティアがウォレット・スティール（wallet-stealer）を追加した、より単純なケースでした。

• Protestware: メンテナーが、2022年のcolorsやfakerで見られたように、政治的な主張をするために、意図的に自分のコードを破壊します。

• External Shocks: プロジェクトは、制裁（メンテナーの管轄区域をブロックする）や、DMCAテイクダウン、あるいは、外部サービス（TwitterやRedditなど）がプロジェクトが依存するAPIを停止させる「API rug-pulls」によって、死に至ることがあります。

パイプラインとエコシステムの失敗

コード自体は問題ありませんが、プロジェクトを届けるためのメカニズムが壊れることがあります。

• Maintained-not-Shipping: 開発はGitで継続されていますが、公開権限を持つアカウントが失われ（例：2FAの紛失）、ユーザーは古いバージョンに留まり続け、修正はレジストリで見えるものの、届かない状態になります。
• Build Archaeology: 公開されたアーティファクト（artifacts）は動作しますが、ビルド環境が失われています。新しいバージョンをリリース・リリースするには、失われたCI設定を再構築するか、5年前のノートパソコンを探し出す必要があります。
• Transitive Death: プロジェクトは健全ですが、3レベル下の依存関係が死にます。小さなユーティリティの失敗が巨大なフレームワークを凍結させるため、依存関係の連鎖によってプロジェクトはこの死を再帰的に引き継ぎます。
• The Registry Orphan: パッケージはレジストリに存在しますが、ソースURLが404エラーになります。ユーザーは、いかなるソースコードに対しても検証ができなくなったtarballをインストールしています。

コミュニティの視点と反論

衰退の分類学は広範ですが、コミュニ-ティは、これらの死が「愚かな」ものか、それとも不可避なものかについて意見が分かれています。一部の人は、毎週のメンテナンスを期待することは、ホビー志向の人々に対する非現実的な現代の税金であると主張しています。

"I didn't sign up as maintainer for life just by simply throwing something on git... The problem is that people... seem to conflate github with linkedin."

他の人々は、「スコープ・クリープ（scope creep）」の危険性、つまり、声の大きいユーザーが特化したツールを「スイス・アーミー・ナイフ」のように多機能化させようとし、単独のメンテナーが維持できないほど複雑にしてしまうことを指摘しています。また、傲慢さゆえにプロジェクトが分裂し、そのフォークが決定的な規模に達することなく枯渇していく「過信的なフォーク（overconfident fork）」のリスクもあります。

最終的に、私たちのロックファイル（lockfiles）におけるこれらの「ゾンビ」パッケージの存在は、一つのリマインダー（reminder）として機能します。オープンソース・プロジェクトの健全性は、最終コミット日によって測定されるのではなく、持続可能な人間のコミュニティの存在によって測定されるべきなのです。