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

Moderne Software wird selten von Grund auf neu gebaut. Stattdessen wird sie wie ein massives Bauwerk aus vorgefertigten Teilen zusammengesetzt, wobei jeder Teil ein kleines Stück Code ist, das von jemand anderem geschrieben wurde. In der Welt von JavaScript ist das System, das diese Teile zusammenhält, als npm bekannt – ein digitales Lagerhaus, in dem Entwickler diese Code-Pakete herunterladen, um alles von Websites bis hin zu mobilen Apps zu bauen. Die meisten dieser Teile werden von Freiwilligen gepflegt, die in ihrer Freizeit daran arbeiten. Wenn ein Freiwilliger aufhört, an einem Teil zu arbeiten, wird dieses Stück Code inaktiv. Es geht nicht sofort kaputt, aber es erhält keine Updates, Fehlerbehebungen oder Sicherheits-Patches mehr. Dies schafft ein verborgenes Risiko: Wenn ein weit verbreiteter Teil aufhört, aktualisiert zu werden, bleiben die tausenden Projekte, die auf ihn angewiesen sind, mit einer Komponente zurück, die nicht repariert werden kann, wenn etwas schiefgeht. Die Frage ist nicht nur, ob diese Teile aufhören, aktualisiert zu werden, sondern wie viele von ihnen tatsächlich inaktiv sind, wie viele Menschen sie tatsächlich nutzen und ob die Menschen, die sie nutzen, wissen, dass sie die Nutzung einstellen müssen.

Ein Forscher namens Revanth Krishna Maddula setzte sich zum Ziel, die populärsten Teile in diesem System zu untersuchen. Er betrachtete fast sechzehntausend Pakete, die mindestens eine Million Mal pro Woche heruntergeladen werden. Dies sind die Kernkomponenten des JavaScript-Ökosystems, die Teile, die das meiste Gewicht tragen. Durch die Untersuchung der vollständigen Geschichte dieser Pakete bis Oktober 2026 wollte er sehen, wie viele aufgehört hatten, neue Versionen zu veröffentlichen, wie viele Menschen sie noch nutzen und wie das System reagierte, wenn ein Teil verstummte. Die Studie konzentrierte sich auf eine spezifische Definition von Inaktivität: ein Paket, das in den letzten zwei Jahren keine stabile, fertige Version veröffentlicht hat. Dieser Zeitraum wurde gewählt, um zwischen Teilen, die einfach fertiggestellt wurden, und Teilen, die aufgegeben wurden, zu unterscheiden.

Die Ergebnisse zeigen, dass Inaktivität weitaus häufiger vorkommt, als man vermuten könnte. Am Ende des Untersuchungszeitraums hatten fast fünfunddreißig Prozent dieser Top-Pakete in den letzten zwei Jahren keine neue Version veröffentlicht. Dieses Schweigen war nicht auf obskure oder selten genutzte Werkzeuge beschränkt; es erreichte das innerste Herz des Systems. Unter den einhundert meistgeladenen Paketen waren sechsundzwanzig Prozent inaktiv. Tatsächlich waren einige dieser stillen Pakete seit mehr als acht Jahren nicht mehr aktualisiert worden. Trotz dieser weit verbreiteten Inaktivität blieb das Schweigen fast immer ungebrochen. Als der Forscher die an diesen Paketen angehängten öffentlichen Notizen prüfte, die als README-Dateien bekannt sind, stellte er fest, dass nur etwa drei Prozent der inaktiven Pakete explizit angaben, dass sie nicht mehr gepflegt würden. Meistens änderte sich der Code einfach nicht mehr, was die Nutzer im Unklaren darüber ließ, ob das Projekt abgeschlossen oder vergessen war.

Die Gefahr dieses Schweigens besteht darin, dass die aktiven Teile des Systems tief mit diesen inaktiven Teilen verbunden sind. Die Studie kartierte die Beziehungen zwischen den Paketen und fand heraus, dass mehr als ein Viertel der aktiv gepflegten Pakete direkt von mindestens einem inaktiven Paket abhing. Einige dieser stillen Pakete waren so zentral, dass sie über Ketten von Abhängigkeiten von mehr als tausend anderen hochfrequentierten Paketen erreichbar waren. Viele davon waren kleine, einfache Werkzeuge, die vor Jahren hätten abgeschlossen sein können, aber andere waren substanzielle Module, die das Fundament für vieles des Software-Toolings bildeten. Das Problem ist, dass Nutzer nicht ohne Weiteres zwischen einem Werkzeug, das fertig ist, und einem, das aufgegeben wurde, unterscheiden können, da das System kein klares Signal liefert, um das eine vom anderen zu unterscheiden.

Wenn eine Abhängigkeit inaktiv wird, reagieren die Menschen, die sie nutzen, normalerweise nicht schnell. Die Studie verfolgte, wie lange es dauerte, bis Nutzer eine Abhängigkeit von einem Paket entfernten, das aufgehört hatte, Updates zu liefern. Über einen Zeitraum von zwei Jahren entfernten Nutzer nur etwa siebenundzwanzig Prozent ihrer Abhängigkeiten von inaktiven Paketen. Diese Rate war nur geringfügig höher als die Rate, mit der sie Abhängigkeiten von aktiven Paketen entfernten, was darauf hindeutet, dass die bloße Tatsache, dass ein Paket aufgehört hatte, aktualisiert zu werden, nicht ausreichte, um eine Reaktion hervorzurufen. Die Forscher testeten, ob unterschiedliche Arten von Warnungen dieses Verhalten veränderten. Sie fanden heraus, dass ein Hinweis in der Dokumentation des Projekts keinen nachweisbaren Effekt darauf hatte, ob Nutzer das Paket entfernten. Das einzige Signal, das Nutzer zuverlässig zum Handeln veranlaste, war eine offizielle Deprecation-Meldung (Veraltigungsmeldung), die vom Registry selbst herausgegeben wurde. Als ein inaktives Paket vom System offiziell als veraltet markiert wurde, entfernten Nutzer die Abhängigkeiten dazu mit einer Rate von fünfundsechzig Prozent. Diese offizielle Warnung, die bei Entwicklern erscheint, wenn sie die Software installieren, war der einzige Mechanismus, der erfolgreich das Ökosystem dazu brachte, sich von dem stillen Code abzuwenden.

Es gibt auch eine Sicherheitsdimension zu dieser Inaktivität. Während die meisten inaktiven Pakete in ihren neuesten Versionen keine bekannten Sicherheitsmängel aufwiesen, befanden sich diejenigen, die es doch taten, in einer prekären Lage. Die Studie fand heraus, dass eine kleine Anzahl inaktiver Pakete bekannte Schwachstellen aufwies, die von ihren ursprünglichen Maintainern nicht mehr behoben werden konnten. Da der Code nicht mehr aktualisiert wurde, konnten diese Fehler nicht von oben her patching-technisch behoben werden. Nutzer, die sich auf diese Pakete verlassen mussten entweder, sie zu entfernen, sie durch andere Werkzeuge zu ersetzen oder die Sicherheitslücken selbst zu schließen. Diese Situation verdeutlicht eine kritische Lücke im System: Wenn ein weit verbreiteter Teil aufhört, gepflegt zu werden, verschiebt sich die Verantwortung für dessen Sicherheit vollständig auf die Menschen, die ihn nutzen – oft ohne deren Wissen.

Die Studie kommt zu dem Schluss, dass Inaktivität ein normaler, stiller Zustand für einen großen Teil des Software-Ökosystems ist. Es ist nicht unbedingt ein Defekt, wenn ein kleines Werkzeug fertiggestellt wurde, aber der Mangel an Kommunikation macht es unmöglich für Nutzer, den Unterschied zu kennen. Die Forschung legt nahe, dass das aktuelle System zu sehr darauf vertraut, dass Nutzer den Status ihrer Werkzeuge erraten. Der effektivste Weg, dieses Risiko zu managen, besteht darin, dass Maintainer den offiziellen Deprecation-Mechanismus verwenden, wenn sie die Arbeit an einem Paket einstellen, idealerweise indem sie die Nutzer auf einen Ersatz hinweisen. Damit das Ökosystem gesund bleibt, muss das Registry Inaktivität und Deprecation sichtbarer machen, um sicherzustellen, dass das Signal die Entwickler erreicht, die es sehen müssen, bevor ein stilles Paket zu einem Problem wird.