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

Moderne software wordt zelden vanaf nul opgebouwd. In plaats daarvan wordt het samengesteld als een enorme structuur van prefab-onderdelen, waarbij elk onderdeel een klein stukje code is dat door iemand anders is geschreven. In de wereld van JavaScript wordt het systeem dat deze onderdelen bij elkaar houdt, npm genoemd, een digitale opslagplaats waar ontwikkelaars deze codepakketten downloaden om alles te bouwen, van websites tot mobiele apps. De meeste van deze onderdelen worden onderhouden door vrijwilligers die er in hun vrije tijd aan werken. Wanneer een vrijwilliger stopt met het werken aan een onderdeel, wordt dat stuk code slapend. Het gaat niet onmiddellijk kapot, maar het ontvangt geen updates, bugfixes of beveiligingspatches meer. Dit creëert een verborgen risico: als een veelgebruikt onderdeel stopt met worden bijgewerkt, blijven de duizenden projecten die er afhankelijk van zijn achter met een component die niet gerepareerd kan worden als er iets misgaat. De vraag is niet alleen of deze onderdelen stoppen met worden bijgewerkt, maar hoeveel van hen daadwerkelijk slapend zijn, hoeveel mensen ze gebruiken, en of de mensen die ze gebruiken weten dat ze er mee moeten stoppen.

Een onderzoeker genaamd Revanth Krishna Maddula zette zich scharpe om de meest populaire onderdelen in dit systeem te onderzoeken. Hij keek naar bijna zestien duizend pakketten die minstens één miljoen keer per week worden gedownload. Dit zijn de kerncomponenten van het JavaScript-ecosysteem, de onderdelen die het meeste gewicht dragen. Door de volledige geschiedenis van deze pakketten te bestuderen tot oktober 2026, wilde hij zien hoeveel ervan gestopt waren met het uitbrengen van nieuwe versies, hoeveel mensen ze nog steeds gebruikten, en hoe het systeem reageerde wanneer een onderdeel stilviel. De studie richtte zich op een specifieke definitie van slaapstand: een pakket dat de afgelopen twee jaar geen stabiele, voltooide versie heeft gepubliceerd. Deze tijdspanne werd gekozen om onderscheid te maken tussen onderdelen die simpelweg voltooid zijn en onderdelen die zijn verlaten.

De bevindingen laten zien dat de slaapstand veel gebruikelker is dan velen zouden verwachten. Aan het einde van de onderzoeksperiode had bijna vijfendertig procent van deze top-pakketten in twee jaar geen nieuwe versie uitgebracht. Deze stilte was niet beperkt tot obscure of zelden gebruikte tools; het bereikte het hart van het systeem. Onder de honderd meest gedownloade pakketten waren zesentwintig procent slapend. Sterker nog, sommige van deze stille pakketten waren al meer dan acht jaar niet meer bijgewerkt. Ondanks deze wijdverspreide inactiviteit, werd de stilte bijna altijd ononderbroken. Wanneer de onderzoeker de openbare aantekeningen controleerde die bij deze pakketten horen, bekend als README-bestanden, ontdekte hij dat slechts ongeveer drie procent van de slapende pakketten expliciet vermeldde dat ze niet langer werden onderhouden. Meestal veranderde de code simpelweg niet meer, waardoor gebruikers moesten raden of het project voltooid of vergeten was.

Het gevaar van deze stilte is dat de actieve onderdelen van het systeem diep verbonden zijn met deze slapende onderdelen. De studie bracht de relaties tussen de pakketten in kaart en vond dat meer dan een kwart van de actief onderhouden pakketten direct afhankelijk was van ten minste één slapend pakket. Sommige van deze stille pakketten waren zo centraal dat ze via ketens van afhankelijkheden bereikbaar waren vanuit meer dan duizend andere pakketten met veel verkeer. Veel van deze waren kleine, eenvoudige tools die jaren geleden voltooid hadden kunnen zijn, maar anderen waren substantiële modules die de basis vormden voor veel van de softwaretooling. Het probleem is dat gebruikers niet gemakkelijk het verschil kunnen zien tussen een tool die voltooid is en een die is verl порядок (verlaten), omdat het systeem geen duidelijk signaal biedt om de twee te onderscheiden.

Wanneer een afhankelijkheid (dependency) in slaapstand gaat, reageren de mensen die het gebruiken meestal niet snel. De studie volgde hoe lang het duurde voordat gebruikers een afhankelijkheid van een pakket dat gestopt was met updaten, verwijderden. Over een periode van twee jaar verwijderden gebruikers slechts ongeveer zevenenttwintig procent van hun afhankelijkheden op slapende pakketten. Dit percentage lag slechts iets hoger dan het tempo waarmee zij afhankelijkheden op actieve pakketten verwijderden, wat suggereert dat het loutere feit dat een pakket gestopt was met updaten, niet genoeg was om actie te stimuleren. De onderzoekers testten of verschillende soorten waarschuwingen dit gedrag veranderden. Ze ontdekten dat een noot in de documentatie van het project geen detecteerbaar effect had op of gebruikers het pakket verwijderden. Het enige signaal dat gebruikers betrouwbaar tot actie liet overgaan, was een officiële deprecatiebericht uitgegeven door de registry zelf. Wanneer een slapend pakket formeel als deprecated werd gemarkeerd door het systeem, verwijderden gebruikers hun afhankelijkheden ervan met een snelheid van vijfenzestig procent. Deze officiële waarschuwing, die bij ontwikkelaars verschijnt wanneer zij de software installeren, was het enige mechanisme dat er erin slaagde het ecosysteem weg te leiden van de stille code.

Er is ook een beveiligingsdimensie aan deze slaapstand. Hoewel de meeste slapende pakketten geen bekende beveiligingsfouten hadden in hun laatste versies, bevonden die met bekende kwetsbaarheden zich in een precaire positie. De studie vond dat een klein aantal slapende pakketten bekende kwetsbaarheden bevat die niet langer door de oorspronkelijke beheerders kunnen worden hersteld. Omdat de code niet langer wordt bijgewerkt, kunnen deze gebreken niet van bovenaf worden gepatcht. Gebruikers die op deze pakketten vertrouwden, moesten ze ofwel verwijderen, vervangen door andere tools, of de beveiligingslekken zelf repareren. Deze situatie benadrukt een kritiek gat in het systeem: wanneer een veelgebruikt onderdeel stopt met worden onderhouden, verschuift de verantwoordelijkheid voor de veiligheid ervan volledig naar de mensen die het gebruiken, vaak zonder hun medeweten.

De studie concludeert dat de slaapstand een normale, stille staat is voor een groot deel van het software-ecosysteem. Het is niet noodzakelijkerwijs een defect als een kleine tool voltooid is, maar het gebrek aan communicatie maakt het onmogelijk voor gebruikers om het verschil te weten. Het onderzoek suggereert dat het huidige systeem te veel vertrouwt op het gissen van gebruikers naar de status van hun tools. De meest effectieve manier om dit risico te beheersen, is door beheerders de officiële deprecatie-mechanisme te laten gebruiken wanneer ze stoppen met een pakket, bij voorkeur door gebruikers naar een vervanger te wijzen. Voor een gezond ecosysteem moet de registry de slaapstand en deprecatie zichtbaarder maken, zodat het signaal de ontwikkelaars bereikt die het moeten zien voordat een stil pakket een probleem wordt.