Dormant at the core: Inactivity, dependence and exit among the most downloaded npm packages

現代のソフトウェアは、ゼロから構築されることは滅多にありません。その代わりに、誰かが書いた小さなコードの断片である「既製品のパーツ」を組み合わせて作られる巨大な構造物のように組み立てられます。JavaScriptの世界では、これらのパーツを繋ぎ止めるシステムはnpmと呼ばれており、開発者がウェブサイトからモバイルアプリまであらゆるものを構築するために、これらのコードパッケージをダウンロードするためのデジタル倉庫となっています。これらのパーツの多くは、空き時間に作業するボランティアによって維持されています。ボランティアがそのパーツの作業をやめると、そのコードの断片は休眠状態になります。すぐに壊れるわけではありませんが、更新、バグ修正、またはセキュリティパッチが止まってしまいます。これは隠れたリスクを生み出します。もし広く使われているパーツの更新が止まれば、それに依存している何千ものプロジェクトは、何か問題が起きたときに修理できないコンポーネントを抱え込むことになるからです。問題は、これらのパーツが更新されなくなるかどうかだけでなく、実際にどれだけの数が休眠しているのか、どれほど多くの人がそれを使用しているのか、そしてそれを使用している人々が使用をやめるべきであることを知っているのかという点にあります。

Revanth Krishna Maddulaという研究者は、このシステムの中で最も人気のあるパーツを調査することにしました。彼は、毎週少なくとも100万回ダウンロードされている約1万6千のパッケージを調査しました。これらはJavaScriptのエコシステムの核となるコンポーネントであり、最も大きな影響力を持つパーツです。彼は、2026年10月までのこれらパッケージの完全な履歴を研究することで、どれだけの数が新しいバージョンをリリースするのを止めたのか、どれほどの人が依然としてそれらを使用しているのか、そしてあるパーツが沈黙したときにシステムがどのように反応するかを調べようとしました。研究では、特定の「休眠」の定義に焦点を当てました。それは、「過去2年間に安定した完成版を公開していないパッケージ」です。この期間設定は、単に完成したパーツと、放棄されたパーツを区別するために選ばれました。

調査結果は、休眠が予想以上に一般的であることを明らかにしています。研究期間の終了時、これらトップパッケージの約35パーセントが2年間新しいバージョンをリリースしていませんでした。この沈黙は、無名あるいは滅多に使われないツールに限られたものではなく、システムの核心部分にまで及んでいました。最もダウンロードされている100個のパッケージのうち、26パーセントが休眠状態にありました。実際、これらの沈黙したパッケージの中には、8年以上も更新されていないものもありました。このような広範な不活性状態にもかかわらず、沈黙はほとんどの場合、破られることがありませんでした。研究者がこれらのパッケージに付随する公開ノート、いわゆるREADMEファイルを確認したところ、休眠しているパッケージのうち、明示的に「現在はメンテナンスを行っていない」と述べているものは、わずか3パーセント程度でした。ほとんどの場合、コードはただ変化を止めただけであり、ユーザーはプロジェクトが完成したのか、それとも忘れ去られたのかを推測するしかありませんでした。

この沈黙の危険性は、システムの活動的なパーツが、これらの休眠しているパーツと深く結びついていることにあります。研究ではパッケージ間の関係をマッピングし、能動的にメンテナンスされているパッケージの4分の1以上が、少なくとも1つの休眠しているパッケージに直接依存していることを発見しました。これらの沈黙したパッケージの中には、1,000以上の高トラフィックなパッケージからの依存関係の連鎖を通じて到達可能なほど、中心的なものもありました。これらは数年前に完了した可能性のある小さく単純なツールであることもあれば、ソフトウェア・ツーリングの基礎を形成する実体のあるモジュールであることもありました。問題は、ユーザーが「完成したツール」と「放棄されたツール」の違いを容易に判別できないことです。なぜなら、システムには両者を区別するための明確なシグナルが存在しないからです。

依存関係が休眠状態になると、それを使用している人々は通常、迅速には反応しません。研究では、更新が止まったパッケージに対する依存関係をユーザーが削除するまでにどれくらいの時間がかかるかを追跡しました。2年間の調査期間中、ユーザーが休眠中のパッケージへの依存関係を削除した割合は約27パーセントでした。この割合は、活動的なパッケージへの依存関係を削除する割合よりもわずかに高い程度であり、単にパッケージの更新が止まったという事実だけでは、行動を促すには不十分であったことを示唆しています。研究者たちは、異なる種類の警告がこの行動を変えるかどうかをテストしました。その結果、プロジェクトのドキュメント内の注記は、ユーザーがパッケージを削除するかどうかに検知可能な影響を与えないことが分かりました。ユーザーの行動を確実に引き起こした唯一のシグナルは、レジストリ自体によって発行された公式の非推奨（デプリケーション）通知でした。休眠中のパッケージがシステムによって正式に非推奨としてマークされると、ユーザーはそれに対する依存関係を65パーセントの割合で削除しました。開発者がソフトウェアをインストールする際に表示されるこの公式の警告こそが、エコシステムを沈黙したコードから離脱させることに成功した唯一のメカニズムでした。

また、これにはセキュリティの側面もあります。ほとんどの休眠パッケージは最新バージョンにおいて既知のセキュリティ上の欠陥を持っていませんでしたが、欠陥を持っていたものは非常に危うい立場にありました。研究によると、少数の休眠パッケージには既知の脆弱性が含まれていましたが、元のメンテナーによって修正することができなくなっていました。コードが更新されていないため、これらの欠陥は上層部からパッチを当てる（修正する）ことができません。これらのパッケージに依存しているユーザーは、それらを削除するか、別のツールに置き換えるか、あるいは自分自身でセキュリティの穴を修正しなければなりませんでした。この状況は、システムにおける決定的なギャップを浮き彫りにしています。広く使われているパーツのメンテナンスが止まったとき、その安全に対する責任は、しばしばユーザーの知らないうちに、完全に使う側の責任へと移ってしまうのです。

研究は、休眠がソフトウェア・エコシステムの大部分にとって、正常かつ静かな状態であることを結論づけています。小さなツールが完成していることは必ずしも欠陥ではありませんが、コミュニケーションの欠如により、ユーザーがその違いを知ることは不可能です。研究は、現在のシステムがユーザーの「推測」に頼りすぎていることを示唆しています。このリスクを管理する最も効果的な方法は、メンテナーがパッケージの作業を止める際に、公式の非推奨メカニズムを使用し、理想的にはユーザーに対して代替品を提示することです。エコシステムが健全であり続けるためには、レジストリが休眠と非推奨化をより可視化し、沈黙したパッケージが問題になる前に、そのシグナルが開発者に確実に届くようにする必要があります。