GitHub `pushed_at` gaf een verkeerd beeld bij 14 van de 35 scraping-repositories; bij drie zijn bots bevestigd

GitHub's repositorypagina toont pushed_at, een tijdstempel dat kan veranderen zodra er naar eender welke branch iets wordt gepusht. Daardoor kan het afwijken van de nieuwste commit op de standaardbranch. De datum van de standaardbranch is een signaal voor repository-onderhoud; het is niet per se de code die een package manager installeert.

Package managers lossen doorgaans registry-artifacts of moduleversies op. Daarom bekijkt deze audit repository-activiteit en het gepubliceerde artifact apart: de ene kan actueel zijn terwijl de andere verouderd is.

Ik heb daarom 35 repos verzameld die nog steeds in aanbevelingen opduiken, en gekeken naar het getal dat GitHub niet in de header zet: de datum van de nieuwste commit op de standaardbranch.

De afwijking is echt: bij 14 van de 35 ligt pushed_at meer dan 180 dagen vóór de laatste commit op de standaardbranch, met als uiterste 1.802 dagen. Bij drie van die 14 zijn bots aantoonbaar bevestigd; na filtering op gearchiveerde projecten en menselijke activiteit blijven twee bevestigde botgevallen over binnen negen kandidaten. De nuttigere conclusie is dat de actualiteit van repository en gepubliceerd artifact uiteen kan lopen.

Wat is gemeten, en waarop

Officiële bron: GitHub repository API.

Alle cijfers hier zijn gelezen uit een live API-response tussen 15:44 en 15:53 UTC op 2026-07-27 en gecached. De dataset met 35 regels, de repositorylijst, de samengestelde regels, en de fetch/build-scripts in artifacts/ bewaren de audit-inputs en transformatielogica.

Er zijn vier datacategorieën verzameld; registry- en activity-aanvragen waren conditioneel en niet simpelweg één vaste reeks van vier calls:

• GET /repos/{owner}/{repo} — stars, archived, pushed_at, license, default_branch.
• GET /repos/{o}/{r}/commits?sha={default_branch}&per_page=1 — de nieuwste commit op de standaardbranch, gebruikt als signaal voor repository-onderhoud.
• GET /repos/{o}/{r}/activity?per_page=30 — voor elke repo waarbij die twee verschillen, wat pushed_at daadwerkelijk heeft verschoven.
• GET /repos/{o}/{r}/releases plus de PyPI- en npm-registry's — wanneer het artifact voor het laatst is uitgebracht; dat blijkt belangrijker dan beide andere signalen.

staleness_days is de verstreken tijd vanaf de commit op de standaardbranch tot het gekozen moment van meting. Het gat tussen pushed_at en die commit is de illusie, gemeten in dagen. Alles boven 180 dagen wordt gemarkeerd.

Twee uitgangspunten zijn belangrijk om te noemen, omdat ze de uitkomst hebben veranderd.

Package-toewijzing is geverifieerd, nooit afgeleid. Een package waarvan de README naar een repo verwijst, is niet automatisch het package van die repo. Elke koppeling moest worden bevestigd via een gestructureerd veld — de eigen repository/project_urls-vermelding van de registry, of een manifest dat in de repo zelf is gecommit. Zes ogenschijnlijk plausibele koppelingen sneuvelden op die toets en hun downloadcijfers worden bewust niet toegeschreven.

Eén van die afwijzingen rechtvaardigt al die voorzichtigheid. curl-cffi haalt 35.763.529 downloads per maand binnen en lijkt van een afstand op de Python-binding voor lwthiker/curl-impersonate — een repo die al 875 dagen stil ligt. Als je die zou toeschrijven, zou je uitkomen op een getal dat 44 keer groter is dan dat van newspaper3k, en het zou onjuist zijn: de eigen PyPI-metadata van curl-cffi verwijst naar lexiforest/curl_cffi, een apart, actief onderhouden project dat voor het laatst verscheen op 2026-04-03. Het spectaculairste getal hier was dus ook meteen het verkeerde.

Een zevende geval is nog vreemder: steel-dev/steel-mcp-server noemt @steel-dev/mcp-server in zijn eigen package.json, maar npm geeft een 404 terug. Het is nooit gepubliceerd, dus “wordt nog steeds geïnstalleerd” kan hier helemaal niet kloppen.

Waar geen getal te achterhalen was, staat dat er ook. Go-, JVM-, .NET- en PHP-tools hebben geen PyPI- of npm-aanwezigheid, dus daar staat N/A (no PyPI/npm package) — nooit nul. Zeventien van de 35 publiceren überhaupt geen GitHub Releases; dat is vastgelegd als none, niet als ontbrekende data.

Deze velden worden bewust niet samengevoegd tot één “gezondheidsscore”. Een verouderde standaardbranch, een recente zijbranch, een ontbrekende GitHub Release en een oud registry-artifact beantwoorden verschillende vragen. Het bewijsmateriaal per rij staat in de dataset met 35 regels, samen met de repository-inputs en samengestelde records. Zie ze als triagesignalen die bepalen wat je als volgende controleert, niet als vier stemmen over de vraag of een project nog leeft.

De samplingvoorbehoud, meteen voorop

Dit is een handmatig samengestelde lijst van tools waarvan ik vermoedde dat ze vooral op reputatie draaiden. Het is geen aselecte steekproef van het scraping-ecosysteem, en "31 van de 35 zijn verouderd" is geen ecosysteempercentage — het zegt vooral iets over hoe goed ik heb geselecteerd. De interessante uitkomst is niet het aantal verouderde repos. Het is dat zelfs in een steekproef die juist op dit fenomeen is gekozen, het specifieke mechanisme dat ik testte slechts een minderheid van de gevallen verklaarde, en nog minder vaak hard kon worden bevestigd.

De illusie is echt, en dit is het ergste voorbeeld

sjdirect/abot, een .NET-crawler met 2.308 stars. GitHub meldt een push op 2026-07-17, tien dagen vóór de meetdatum. De standaardbranch is voor het laatst aangepast op 2021-08-09.

Dat is een gat van 1.802 dagen. Vijf jaar. De header zegt: vorige week.

Veertien van de 35 repos laten een gat van meer dan 180 dagen zien:

Veertien van de vijfendertig. Echt, relevant, en een minderheid van een steekproef die juist zo is gekozen.

Bots zijn bevestigd bij drie gemarkeerde repos — en na filtering blijven er twee over

De populaire versie van dit verhaal noemt altijd dependabot. Ik heb dat gecontroleerd door voor elke gemarkeerde repo de activity-feed op te halen en elke ref te classificeren die na de laatste commit op de standaardbranch is gepusht. Dat “na” is belangrijk: events van vóór de laatste commit zeggen niets over wat het gat heeft veroorzaakt, en als je de hele feed telt, verander je stilletjes de vraag.

Bevestigd als bot-gedreven, volgens de post-commit-methode: drie. scrapinghub/splash (4 van 4 post-commit-events op dependabot/pip/*), geziyor/geziyor (5 van 5 op dependabot/go_modules/*), apache/any23 (16 van 16 op dependabot/maven/*). Een van die drie, any23, is formeel gearchiveerd, dus die valt nooit in de gefilterde set — waardoor er twee bevestigde gevallen overblijven die ook aan alle andere voorwaarden voldoen.

Gewoon fout: twee, en allebei interessanter dan het botverhaal.

Het gat van 1.520 dagen bij dragnet-org/dragnet komt door een mens die een branch mp/py3.10 pusht — een niet-gemergde Python 3.10-port. Iemand probeerde het project vooruit te helpen en stopte ermee. Dat is geen geautomatiseerde ruis die een tijdstempel opblaast; dat is een zichtbaar, gedateerd spoor van een mislukte reddingspoging. Eigenlijk is dit misschien wel het bruikbaarste signaal in de hele dataset, en het frame “dependabot deed het” zou dat uitwissen.

Gemengd, en groter dan beide andere: twee. crawlab-team/crawlab heeft 12.250 stars — de op één na meest geliefde repo in de steekproef — en een gat van 488 dagen op main. In de activity-feed staan dependabot-branches én 24 post-commit pushes van mensen, allemaal naar develop en test. Wie alleen de header leest, ziet februari 2026 en denkt: actief. Wie alleen main bekijkt, ziet oktober 2024 en denkt: dood. Beide interpretaties zijn fout. De ontwikkeling is verplaatst van de standaardbranch, en GitHub’s samenvattingsweergave kan dat niet goed laten zien. sjdirect/abot is het andere gemengde geval: de push die de headline pushed_at opleverde was inderdaad van dependabot, maar een mens pusht in 2024 upgrade1, waardoor het later uit de gefilterde set valt.

Rhizome-Conifer/conifer is het twijfelgeval, en ik las dat eerst verkeerd. De standaardbranch is main, niet master, en main staat sinds 2023-10-12 stil — het enige main-event in de feed is het aanmaken van een branch in januari 2025, passend bij een naamswijziging. Tegelijkertijd pusht één account op 2026-07-22 naar conifer-twilight en twilight/read-only, vijf dagen vóór de meetdatum. Dat is echte menselijke activiteit, maar “actief in ontwikkeling” is sterker dan wat deze refs aantonen: één contributor, op branches met de naam read-only, past minstens even goed bij een gecontroleerde uitfasering als bij lopende ontwikkeling. Wat wel gezegd kan worden, is smaller maar nog steeds relevant: het gat van 1.013 dagen is geen bot-ruis, en ook geen bewijs van abandonneren.

Onbekend: zeven. php-html-parser, simhash-py, internetarchive/wayback, boilerpipe, waybackurls, wpull en crawler4j hebben allemaal een geverifieerd gat en een activity-feed die leeg terugkomt.

De verleiding is om retention als verklaring te gebruiken — GitHub's activity-feed gaat niet eeuwig terug. De cache weerlegt dat voor de meesten. Het oudste event in al deze 123 responses is 2023-03-10, en vijf van de zeven zitten ruim binnen dat venster: php-html-parser 2024-08-09, wpull 2024-04-29, waybackurls 2024-05-01, internetarchive/wayback 2024-03-01, simhash-py 2023-05-15. Wat die tijdstempels ook heeft verplaatst, had in de feed zichtbaar moeten zijn — en was dat niet. Retention verklaart alleen boilerpipe (2018) en crawler4j (2021).

De eerlijke conclusie is dus dunner dan een nette verklaring: voor zeven repos is het gat een vastgesteld feit en de oorzaak niet aangetoond — de endpoint gaf niets terug, en voor vijf daarvan kan ik niet zeggen waarom. "Dependabot deed het" is voor alle zeven een aanname.

Opgeteld, over de 14 gemarkeerde repos:

De rijen tellen op tot 14. Ze classificeren wat pushed_at heeft verschoven; ze bewijzen niet los van elkaar of een project verlaten is.

Wat overblijft na de volledige filter, en wat "overblijft" betekent

De oorspronkelijke claim heeft vier dingen tegelijk nodig: langer dan een jaar verouderd, pushed_at meer dan 180 dagen opgeblazen, niet gearchiveerd, en geen aanwijzing dat de inflatie door menselijk werk kwam. Negen van de 35 kandidaten halen alle vier, hier opgesomd naast de twee belangrijkste uitzonderingen:

Dat getal heeft een nuance nodig die de filter niet kan dragen. Alleen twee van de negen — splash en geziyor — hebben positief bewijs dat bots de inflatie veroorzaakten. De andere zeven halen de vierde voorwaarde doordat er geen bewijs in beide richtingen is. Het zijn gevallen die de claim doorstaan, niet gevallen die die claim bevestigen. En de sterkste bevestiging in de hele audit, any23 met 16 van de 16 dependabot-events, valt buiten de selectie omdat de repo gearchiveerd is.

Merk ook op dat abot, het geval van 1.802 dagen, niet bij die negen zit. Het record bevat een menselijke push, dus het voldoet niet aan de vierde voorwaarde — de meest spectaculaire illusie in de dataset is dus geen zuiver voorbeeld van het mechanisme dat het illustreert.

Voor 21 van de 35 rapporteerde GitHub de veroudering gewoon duidelijk

Hier is de bevinding die mijn hypothese het meest heeft aangetast. Veertien repos hebben een gat van exact nul, en nog eens zeven blijven onder de 180 dagen. Voor 21 van de 35 kandidaten is pushed_at gewoon de laatste commit op de standaardbranch. GitHub verhult hier dus niets.

Inclusief een paar van de doodste dingen uit de steekproef:

BuilderIO/gpt-crawler heeft 22.374 stars en de header zegt al sinds 2025-07-07 hetzelfde. Er wordt niets verborgen, en het aantal installs blijft gewoon doorlopen.

Daarmee verschuift de claim naar iets veel smallers: GitHub verhult veroudering in een minderheid van de gevallen, en in de meerderheid zegt het platform het gewoon expliciet terwijl installs toch doorgaan. Waarom die installs doorgaan, kan deze data niet beantwoorden — de cijfers hier tellen installvolume, geen beslissingen. Maar een UI-aanpassing lost de tweede groep niet op, en dat is de grotere groep.

Repository-activiteit en gepubliceerde artifacts kunnen uiteenlopen

De meest opvallende rij in de dataset breekt het frame volledig open.

codelucas/newspaper — 15.126 stars — is actief. De laatste commit op de standaardbranch is gedateerd op 2026-07-21, tegenover een meetdatum van 2026-07-27, en die commit is door de maintainer zelf gemaakt. Alle repositorycontroles slagen.

Het package dat iedereen installeert is newspaper3k 0.2.8, gepubliceerd op 2018-09-28. Dat is 2.858 dagen oud, en het trekt 813.513 downloads per maand.

De standaardbranch is actueel, terwijl het PyPI-artifact sinds 2018 niet meer is uitgebracht. Dit bewijst een releasegat, niet waarom het package niet meer uitkomt of de pipeline kapot is. Dit is precies het soort risico dat je mist met alleen een repositorycheck, omdat het registry-artifact is dat normaal gesproken draait na pip install newspaper3k.

Zodra je packages in plaats van repos bekijkt, zie je het patroon overal. Van de 17 packages waarvan de repo-koppeling is geverifieerd, zijn er 16 meer dan een jaar geleden voor het laatst uitgebracht, en die 16 zijn samen goed voor ongeveer 2,28 miljoen installs per maand van in totaal 2,30 miljoen:

tls-client verdient een aparte vermelding: 790.305 installs per maand vanuit een repo die al 905 dagen koud is, in een categorie waar actueel blijven juist de kern van het werk is. Browser-TLS-gedrag verandert; een library die dat begin 2024 niet meer bijhoudt, draait op aannames uit begin 2024.

Twee kanttekeningen bij deze tabel. Registry-downloadcijfers tellen ook CI-runs en mirrors mee en dedupliceren niets, dus ze meten installvolume, geen mensen. En de rolling windows hebben niet dezelfde einddatum — die van npm eindigen dicht bij 2026-07-24, die van pypistats zijn relatief aan het ophaalmoment — dus het totaal is een som van iets verschoven maanden en moet worden gelezen als “ongeveer 2,28 miljoen”, niet exact tot op de laatste digit.

De naamsverwarring die het waard is om te kennen

internetarchive/wayback is de dode Java OpenWayback, al 1.916 dagen koud. wayback op PyPI is een volledig ander project — edgi-govdata-archiving/wayback — en dat is gezond, met versie 0.5.1 op 2026-06-19, vijf weken vóór de meetdatum. Zelfde naam, tegenovergestelde toestand, geen enkele relatie. Dit was een van de zes afgewezen attributies, en het is degene die een echte gebruiker het snelst kan raken: zoeken op de naam levert beide op, en op geen van beide pagina’s staat welke je precies hebt gevonden.

Gearchiveerd, gedepricet en nog steeds 127.232 keer per maand geïnstalleerd

Zes repos in de steekproef hebben archived: true, wat GitHub als een banner over de volle breedte toont. Mijn eerste lezing was dat dit bewijst dat mensen luide waarschuwingen negeren. De cache zegt dat het verhaal erger is dan dat.

Officiële bron: npm download-count API-documentatie.

Officiële bron: npm deprecatie-documentatie.

@modelcontextprotocol/server-puppeteer trekt 127.232 installs per maand uit modelcontextprotocol/servers-archived. Maar het npm-veld repository is null — er is dus geen link van de packagepagina terug naar de repo, en de banner is niet iets waar een installateur gewoon langsheen scrolt. De meeste mensen die dit package ophalen, hadden er nooit een route naar via de repo.

Wat npm wél publiceert is de deprecation. De nieuwste versie van het package draagt deprecated: "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." — en npm toont dat in de terminal bij installatie. De waarschuwing wordt dus netjes afgeleverd, precies waar de gebruiker is, en toch gaan er 127.232 installs per maand door. Dat is een sterkere bevinding dan alleen die banner, en die wijst ergens anders heen: het signaal ontbreekt niet, maar komt binnen in een muur van install-uitvoer die niemand hoeft te lezen.

browserbase/mcp-server-browserbase laat zien hoe een nette afsluiting eruitziet: de laatste commit op de standaardbranch, op 2026-07-20, luidt letterlijk "Mark repository as archived and unmaintained (#198)". De maintainers hebben het aangekondigd, gedateerd en in de API gemarkeerd. Die 20.389 installs zijn wel met zorg te lezen — het npm-venster loopt van 2026-06-25 tot 2026-07-24, dus 26 van die 30 dagen liggen vóór de archive-commit. Die aantallen zeggen dus vooral iets over vraag vóór de aankondiging, niet over verzet ertegen. Wat daarna gebeurt is op basis van deze snapshot echt onbekend, en ik zou over een maand opnieuw willen meten voordat ik daar iets stelligs over zeg.

57 stars, 204.025 installs per maand

Janpot/microdata-node heeft 57 stars en trekt 204.025 downloads per maand vanuit een release van 2020-05-11.

Met 57 stars heeft microdata-node relatief weinig zichtbaarheid op repositoryniveau vergeleken met het volume in de registry. De verhouding van 3.579 installs per star past bij indirect gebruik, herhaalde CI-runs, mirrors of direct machinegebruik. Deze audit heeft geen dependency graphs opgehaald en kan niet kiezen tussen die verklaringen.

De rij is een signaal om indirecte blootstelling in kaart te brengen, maar transitief gebruik bewijzen vraagt om reverse-dependency- of lockfile-bewijs dat deze audit niet heeft verzameld.

Verouderd is niet hetzelfde als kapot

Een eerlijke audit moet dit ook zeggen: niets hiervan meet of iets daadwerkelijk stuk is. Het meet of er nog iemand thuis is.

Sommige van deze projecten zijn gewoon af. SetSimilaritySearch implementeert algoritmen voor set-similarity; die slijten niet. simhash is een paper uit 2007. Het content-extraction-algoritme van boilerpipe werkt in 2026 hetzelfde als in 2015 — wat je ook van de nauwkeurigheid op moderne pagina’s vindt, de code is niet onder je vandaan weggedragen.

Wat wél slijt, is alles met een bewegend doel aan de andere kant:

• Browserautomatisering — elke Chrome-release kan het breken.
• HTTP-clientgedrag dat echte browsers nabootst — browsers veranderen, en een bevroren library volgt niet meer; tls-client valt in deze categorie.
• Site-specifieke parsers en extractieregels per site — elke redesign van een site is een bug.
• Alles dat een third-party API wrappt — de vendor wijzigt het schema en jij ontdekt het in productie.
• Alles dat een LLM wrappt — modeldeprecations gaan sneller dan al het andere hier.

Dus “1.606 dagen verouderd” is voor de ene categorie een noodsituatie, en voor een hashing-utility bijna irrelevant. Er is hier geen functionaliteit getest en daarover wordt ook geen claim gedaan; je eigen dependencies indelen naar categorie kost niets en helpt meer dan het verouderingsgetal alleen.

De vier controles die echt antwoord geven op de vraag

Geen daarvan is de repo-header.

Voer controles 1, 2 en 3 uit als snelle triage. Escaleer daarna wanneer repositorymetadata ontbreekt, package-to-repository-attributie dubbelzinnig is, activiteit naar een niet-standaardbranch is verplaatst, of het registry-artifact afwijkt van de repository. De unauthenticated GitHub-limieten en registry-latency maken een belofte van één seconde onrealistisch.

Als een controle iets kouds in een bewegende categorie oplevert, zijn de onderhouden alternatieven in dit vakgebied in onze eigen tests gedocumenteerd: Trafilatura voor content extraction zoals dragnet en boilerpipe dat vroeger deden, Scrapy of Crawlee voor crawling-frameworks, Crawl4AI en Firecrawl voor LLM-gerichte extractie, en Scrapling waar veerkracht telt. Onze open-source scraper pillar houdt het bredere overzicht bij. Dat zijn first-party reviews; voer zelf die vier controles uit voordat je op welke aanbeveling dan ook vertrouwt, ook op de onze.

Beperkingen van deze data

• Steekproefselectie. Handmatig gekozen vanwege vermoedelijke abandonnering. Hieruit kun je geen ecosysteempercentages aflezen.
• Geen breakage-testing. Geen enkele van deze 35 tools is tegen een live site gedraaid. Veroudering is een onderhoudssignaal, geen functioneel oordeel.
• Downloadcijfers tellen machines mee. CI, mirrors, geen deduplicatie en vensters zonder gedeelde einddatum. Installvolume, geen gebruikers, en geen beslissingen.
• Zeven onbekende oorzaken blijven onbekend. De activity-feed gaf niets terug, en voor vijf van de zeven verklaart retention dat niet. Een leeg vakje laten is beter dan het vullen met de populaire gok.
• staleness_days gebruikt commitdatums. Herschreven of teruggedateerde geschiedenis zou dat vertekenen. Daarvan is niets gedetecteerd, wat niet hetzelfde is als dat het niet bestaat.
• Één meetdatum. 2026-07-27. Verschillende van deze repos zullen veranderd zijn tegen de tijd dat je dit leest — vooral newspaper, dat regelmatig commit. Meet de vier controles opnieuw; citeer mijn datums niet.

Waar een managed service het plaatje verandert

Elke controle hier bestaat omdat je met een self-hosted library zelf de veroudering beheert. Als een bevroren HTTP-client zich niet meer gedraagt als een actuele browser, is dat jouw incident, op welk moment het ook zichtbaar wordt.

Auteursnoot: Thunderbit is ons managed scraping-product. Een managed service verschuift een deel van het onderhoud naar een vendor, maar dekking, reactietijd, lock-in en continuïteit van de leverancier worden dan onderdeel van het risicomodel. Thunderbit is niet geëvalueerd in deze repository-audit.

De eerlijke afweging: je levert het vermogen in om de broncode te lezen, een versie vast te pinnen en het probleem zelf om 2 uur ’s nachts te fixen. Voor een team dat al scrapers onderhoudt, is open source vaak de juiste keuze — en precies daarom zijn die vier controles nodig: zodat je er een beslissing van maakt, in plaats van een aanname.

Probeer Thunderbit voor webdata-extractie

De korte versie

Ik bouwde een lijst om te bewijzen dat GitHub abandonnering verbergt. De illusie is echt voor 14 van de 35 repos en spectaculair in één geval: sjdirect/abot toont een push van vorige week tegenover een standaardbranch die sinds 2021 vaststaat, een gat van 1.802 dagen.

Maar het mechanisme is smaller dan het verhaal. Negen repos halen alle voorwaarden die de claim vereist, en slechts twee van die negen — splash en geziyor — hebben positief bewijs dat bots de inflatie veroorzaakten; de rest haalt de drempel door gebrek aan bewijs. Twee gemarkeerde repos zijn menselijke pogingen om een project nieuw leven in te blazen die mislukten. Eén, crawlab, heeft 12.250 stars en verplaatste de ontwikkeling simpelweg naar develop. Bij zeven kwam de activity-feed leeg terug en retention verklaart daarvan slechts twee, dus de oorzaak is niet vastgesteld maar verondersteld. En voor 21 van de 35 repos rapporteerde GitHub veroudering gewoon correct.

Het ergste geval in de dataset doorstaat alle repo-level checks. codelucas/newspaper werd gecommit op 2026-07-21; newspaper3k, voor het laatst uitgebracht op 2018-09-28, ging die maand 813.513 keer de deur uit. Binnen de steekproef vertegenwoordigen 16 packages met releases ouder dan een jaar samen ongeveer 2,28 miljoen installs per maand.

Controleer de commit op de standaardbranch, de release-datum van het registry, de archived-vlag en het npm deprecation-veld als eerste triage. Los package-to-repository-attributie en ontwikkeling op niet-standaardbranches op vóór je een conclusie trekt.

Probeer Thunderbit voor webdata-extractie Get Started Free

Veelgestelde vragen

Wat is pushed_at en waarom betekent het niet “laatst bijgewerkt”?
pushed_at is het GitHub API-veld achter de activiteitstijdstempel op de repo-pagina, en wordt vernieuwd zodra er naar welke branch dan ook iets wordt gepusht. De nieuwste commit op de standaardbranch is één signaal voor repository-onderhoud, terwijl package managers normaal registry-artifacts of opgeloste moduleversies installeren. In deze audit lieten 14 van de 35 repositories de twee GitHub-datums meer dan 180 dagen uiteenlopen.

Is het altijd dependabot dat die tijdstempel opblaast?
Nee, en dat bleek juist het zwakste deel van het populaire verhaal. Als je alleen events telt die na de laatste commit op de standaardbranch vielen, zijn bots bevestigd in 3 van de 14 gemarkeerde repos (splash 4 van 4, geziyor 5 van 5, any23 16 van 16). Bij 2 is het ronduit onjuist: het gat bij dragnet komt van een mens die een niet-gemergde Python 3.10-port pushte. Twee andere zijn gemengd, waaronder crawlab, waar 24 menselijke pushes naar develop en test gingen terwijl main stil stond. En bij 7 gaf de activity-feed helemaal niets terug, dus de oorzaak is niet vastgesteld — retention verklaart daarvan slechts twee.

Betekent een verouderde repo dat de tool kapot is?
Niet op basis van dit bewijs — niets hier is tegen een live site uitgevoerd. Veroudering telt in verhouding tot hoe snel het doel verandert: browserautomatisering, HTTP-clients die browsergedrag nabootsen, site-specifieke parsers en API/LLM-wrappers verouderen snel, terwijl algoritmische libraries zoals SetSimilaritySearch of simhash jaren oud kunnen zijn en prima blijven werken. tls-client is in de steekproef het scherpste geval: 790.305 installs per maand vanuit een repo die al 905 dagen koud is.

Hoe kan een repo actief zijn maar het package toch dood?
Dat is codelucas/newspaper, en het is het meest impactvolle wat deze audit vond. De standaardbranch werd gecommit op 2026-07-21, dagen vóór de meetdatum, maar newspaper3k op PyPI bracht voor het laatst 0.2.8 uit op 2018-09-28 — 2.858 dagen geleden — en trekt nog steeds 813.513 downloads per maand. Repo-level checks slagen allemaal; het artifact dat je installeert is acht jaar oud. Controleer altijd de meest recente publicatiedatum van de registry apart van het commitlog.

Maken gearchiveerde repos dit niet simpel? GitHub toont toch een banner.
Niet betrouwbaar, en @modelcontextprotocol/server-puppeteer laat zien waarom. Het npm-veld repository is null, dus er is geen link van het package naar de gearchiveerde repo en geen banner waar je langsheen kunt lopen. Wat npm wél toont is de deprecated-string van het package — "Package no longer supported" — die bij installatie wordt afgedrukt, en 127.232 installs per maand gaan daar gewoon doorheen. browserbase/mcp-server-browserbase kondigde zijn stopzetting netjes aan in zijn laatste commit; de 20.389 installs daarvan dateren grotendeels van vóór die commit, en zeggen dus weinig in beide richtingen.

Hoe controleer ik snel mijn eigen dependencies?
Begin met de datum van de laatste commit op de standaardbranch, de registry-versie/upload-datum, het npm deprecation-veld en de archived-vlag van de repository. Verifieer daarna de package-to-repository-attributie, inspecteer niet-standaardbranches wanneer activiteit afwijkt, en gebruik dependency graphs of lockfiles voordat je blootstelling als transitief bestempelt. Naamsverwarring zoals de niet-verwante Java- en PyPI-projecten wayback maakt die escalatie noodzakelijk.