オープンソースプロジェクトって、なんとなく「誰かがずっと面倒を見てくれるもの」だと思われがちです。
でも Andrew Nesbitt のこの記事は、その幻想をかなり痛快に、そして少し不穏に壊してくれます。
テーマはシンプルで、**オープンソースプロジェクトには“くだらないほどいろいろな死に方がある”**という話です。
しかも面白いのは、「死んだ」の定義が1つじゃないこと。
最後のコミットが何年も前なのに誰も気づかないケースもあれば、コードは更新されているのにリリースできないケースもある。
見た目では元気そうなのに、内部はもう機能していない。そんな“ゾンビ状態”がたくさんある、というわけです。
私はこの視点、かなり本質的だと思いました。
オープンソースの世界って、「GitHubにコードがある＝生きている」と誤解されがちですが、実際にはそんな単純な話ではありません。
動くコードがあることと、保守できることと、安全に使い続けられることは別問題なんですよね。
記事では、原因をかなり細かく分類していますが、ざっくり言うと次の2系統です。
この切り分けがわかりやすいです。
「人がいない」だけが問題じゃないし、「人はいる」のに前に進めないこともある。
そしてそのどちらも、外から見ると似たように“死んで見える”のが厄介です。
最も典型的なのがこれ。
最後の人間のコミットが何年も前で、issue には未返信がたまり続ける。でもリポジトリは archive されていないので、「死んだ」と判定しづらい。
単に別のことをしているだけの場合もあれば、最悪、メンテナが亡くなっている場合すらある。
外からは区別できない、というのが怖いところです。
企業が作って公開したものの、組織改編やレイオフで担当チームが消えるパターン。
README には会社ロゴが残ったまま、でも誰も責任を持っていない。
大企業ほど、こういう“放置された資産”が増えやすいのではないかと思います。
インフラ系だと、なおさら目立たないまま放置されがちです。
研究室や大学院の課題で作られたソフトが、卒業でいきなり行き場を失うケース。
学術界では、他人のコードを保守しても論文にはならないので、引き継ぐインセンティブが弱い。
これはかなり根深い問題です。
研究は新規性が大事なので、「前任者の作ったものを維持する」作業が評価されにくいんですよね。
助成金や期限付きスポンサー資金が切れて終わるパターン。
プロジェクト自体はフルタイム前提で育っていたのに、資金が終わった瞬間から夜や週末の作業に縮む。
でもその規模のプロジェクトを、空き時間だけで維持するのは現実的ではないことが多い。
README にスポンサーのロゴだけ残る、という描写が妙にリアルで、ちょっと切ないです。
メンテナが企業に雇われ、その会社の事情や負荷のせいで外部OSSを続けられなくなるケース。
悪意がなくても起きるのがポイントです。
特に、企業によっては社員が外部OSSにあまり関われない文化があるので、就職した瞬間にプロジェクトが静かになることもある。
「引き継いでから入社する」のが理想だけど、現実にはなかなか難しいんですよね。
後継者はいるのに、権限が移せないパターン。
npm や registry の publish 権限が昔のアカウントに紐づいたままで、GitHub の admin もいない。
しかも手続きが長くて面倒。
この記事はここをかなりうまく突いていて、**“fork して名前を変えた方が早い”** という皮肉が効いています。
技術的には解決できるのに、制度が遅くて止まる。こういうの、OSSの弱点としてかなり多いと思います。
コミットはある。返信もある。だけど、重要な設計判断や調査が必要な issue は永遠に放置される。
これ、かなり身に覚えがある人も多いのではないでしょうか。
「完全に死んでるわけじゃないから、fork するのも気が引ける」
でも「このままでは進まない」。
いちばん扱いに困る状態です。
すごく現代的な死に方です。
コミットの大半は bot。Dependabot が依存関係を更新し、自動マージされる。
見た目は活発でも、人間はほとんど何も読んでいない。
つまり、更新されているように見えるが、実際には“自動運転で灯りがついているだけ”。
recency-based な健全性スコアが当てにならない、という指摘はかなり鋭いです。
共同メンテナ同士が仲違いして、互いに止め合う状態。
権限はあるのに、協力できない。
これも地味に多そうです。
技術の問題というより、人間関係の問題でプロジェクトが凍る。
オープンソースはコードの共同作業ですが、同時に“人の組織”でもあるんだな、と再認識させられます。
コードは動くしテストも通る。でも、なぜそうなっているのかを理解していた人がいない。
これが本当に怖い。
触るのが怖くなるので、プロジェクトは実質「読み取り専用」になります。
特に数値計算やパーサーのように、裏で複雑なアルゴリズムが動いている分野では起こりやすいそうです。
私はこれ、ソフトウェアの“記憶喪失”みたいなものだと思いました。
メンテナが排他的で、新規貢献者が入ってこない。
結果として bus factor が1のまま固定される。
bus factor というのは「その人が突然いなくなったら何人が困るか」の目安です。
要するに、1人しか知らないプロジェクトは危険、という話ですね。
ここで面白いのは、表面上は commits も issue も動いていて健康そうに見えること。
でも、コミュニティが枯れているので、最後は一気に崩れます。
権限を持つ人が、敵対的な第三者に握られるケース。
xz の件はかなり有名で、長期間の社会的な信用獲得を使った巧妙な攻撃でした。
event-stream も、権限移譲の甘さから危険なコードが混入した例として知られています。
ここで重要なのは、**“メンテナが増えたから安心”ではない**こと。
むしろ、増えたメンテナが本当に信頼できるのかが問題になります。
作者が自分で自分のパッケージを壊すパターン。
colors や faker、node-ipc の例が挙げられています。
理由は抗議だったり政治的メッセージだったり、いろいろですが、下流利用者から見れば被害は同じです。
「公開されているコードを信じていたのに、ある日突然それが別物になる」
これ、OSSの自由さがそのまま不安定さにもつながる例だと思います。
開発は続いているのに、リリースが切れない。
publish 権限を持つアカウントが消えた、2FA デバイスが失われた、会社がなくなった。
この状態だと、GitHub の main ブランチには fix があるのに、利用者は古い公開版を使い続けるしかありません。
これ、かなりつらいです。
“コードはあるのに配布されない”というのは、ソフトウェアの死の中でもかなり実害が大きいと思います。
main は進んでいるけど、最後の tag から遠すぎて、今さら release すると破壊的変更になる。
だから誰も tag を打てない。
新しい contributors は main に patch を入れるけど、ユーザーは古い版のまま。
こうして溝が広がっていく。
「リリース」が一つの仕事として成立しているのに、それを担当する人がいないと止まる、という典型ですね。
ビルドは昔はできたが、今は再現できない。
古い CI、消えた base image、手元にしかなかった toolchain。
新しい release を作るには、まず“昔のビルド環境を考古学的に掘り起こす”必要がある。
この表現がうまいです。
技術的には保存されているはずなのに、再現性がないと実質的には失われたも同然なんですよね。
公開 repo はあるけど、実際の開発は会社の private monorepo でやっていて、外には定期的な同期だけ落ちてくる。
外から見ると ghost maintainer と似ていますが、実態は「公開されているのにオープンではない」状態。
これはかなり現代的な違和感があります。
OSS の顔をしているけど、実は closed source の配布窓口になっているだけ、というケースです。
ある major version は死んでいるのに、別の major version は生きている。
利用者の大半が古い版に張り付いていて、そっちはもう面倒を見てもらえない。
「このプロジェクトは死んだのか？」という問いに、バージョンによって答えが変わるのが面白いところです。
実際、ソフトウェアの寿命って単純な一本線じゃないんですよね。
パッケージは registry で解決できるのに、source repo の URL が 404。
つまり、issue も fork もできないし、tarball が本当にソース由来かも確認しづらい。
これは地味だけどかなり危ない。
パッケージマネージャがあるから安心、ではなく、参照先の整合性が壊れると一気に不透明になるという話です。
制裁や輸出規制で、メンテナ本人は動けるのに registry に push できない。
外から見ると ghost maintainer に見えるけれど、本人は別の場所で状況を説明していることもある。
ここはOSSの外側にある政治・法制度の影響が、そのままソフトウェアの寿命を決める例です。
DMCA や商標問題で削除されるケース。
youtube-dl は戻ってきた例として触れられていますが、規模の小さいプロジェクトは戻れないことも多い。
重要なのは、正当性の議論と、レジストリ上で存在し続けるかどうかは別だという点。
法律やプラットフォームの都合で、配布が止まることは普通にあるんですね。
古い runtime や OS に縛られて、前に進めない。
Python 2 のみ対応、Node の古いバージョンが必要、消えた compiler extension に依存、など。
移植するより、新しく作った方が早いこともある。
でも“使われている以上、完全放棄もできない”。
この中途半端さが長く残るのが厄介です。
自分の依存先が死んで、その死を引き継ぐパターン。
プロジェクト自身は元気でも、下の層が壊れているのでどうにもならない。
これはかなりメタな話で、依存の連鎖そのものが脆さを増幅することを示しています。
OSS って便利だけど、つながりが深いぶん、連鎖的に壊れるんですよね。
外部APIやプラットフォームの仕様変更で、ラッパーが無力化される。
Twitter 2023 の変更や Reddit の変更で、似たようなものが大量に死んだという指摘は納得感があります。
ブラウザやOS側の仕様変更でも同じことが起きる。
つまり、アプリのコードが生きていても、土台のサービスが引き抜かれたら終わるんです。
最後は、そもそも不要になったケース。
新しい言語仕様で代替できるようになったり、標準機能に吸収されたりする。
これは悲しいけど健全な死でもあります。
object-assign が Object.assign に取って代わられた話などは、まさに技術の進歩の結果です。
こういう消え方なら、むしろ成功と言えるかもしれません。
個人的にいちばん面白いのは、この記事が「死んでいるかどうか」を単純に判定しないところです。
オープンソースの健全性って、コミット数だけでも issue の数だけでも測れない。
人、権限、制度、資金、外部サービス、法的リスク、依存関係が全部絡んでいる。
だからこそ、死に方もこんなに多彩になる、というわけです。
そして、これは怖い話でもあります。
なぜなら、私たちが日々使っているライブラリやツールの多くは、見えないところでこのどれかに引っかかっているかもしれないからです。
「便利だなあ」で済ませがちですが、裏ではかなり繊細なバランスで成り立っている。
オープンソースは自由で強い一方、持続性は自動ではない。この記事はその事実を、かなりユーモラスに、でも容赦なく見せてくれます。
この記事は、オープンソースプロジェクトの終わり方を“悲観的”に語るというより、現実的に分解して見せる記事です。
「メンテナがいなくなる」だけでなく、「いても動けない」「動いていても危ない」「リリースできない」「依存先が死ぬ」など、死のパターンは本当に多い。
そして、私が強く感じたのは、
プロジェクトの寿命はコードの寿命より短いことがある
という事実です。
コードは残る。でも、運営する人、支える制度、公開する仕組みが消えたら、プロジェクトとしてはもう機能しない。
そこがオープンソースの面白さであり、同時に弱さでもあると思います。
