GitHubs `pushed_at` führte bei 14 von 35 Scraping-Repositories in die Irre; bei drei wurden Bots bestätigt

GitHubs Repository-Seite zeigt pushed_at an — einen Zeitstempel, der sich ändern kann, sobald auf irgendeinen Branch gepusht wird. Deshalb kann er vom neuesten Commit auf dem Standard-Branch abweichen. Das Datum des Standard-Branches ist ein Signal für die Repo-Pflege; es sagt aber nicht zwingend etwas über den Code aus, den ein Paketmanager installiert.

Paketmanager lösen in der Regel Registry-Artefakte oder Modulversionen auf. Genau deshalb prüft dieser Audit Repository-Aktivität und veröffentlichtes Artefakt getrennt: Das eine kann aktuell sein, während das andere bereits veraltet ist.

Also habe ich 35 Repos herausgezogen, die noch in Empfehlungen auftauchen, und die Kennzahl ausgelesen, die GitHub nicht im Header zeigt: das Datum des neuesten Commits auf dem Standard-Branch.

Die Abweichung ist real: Bei 14 von 35 liegt pushed_at mehr als 180 Tage vor dem letzten Commit auf dem Standard-Branch — der größte Abstand beträgt 1.802 Tage. In drei dieser 14 Fälle wurden Bots eindeutig bestätigt; nach Ausschluss archivierter Repos und menschlicher Aktivität bleiben unter neun Kandidaten zwei bestätigte Bot-Fälle übrig. Die eigentliche Erkenntnis ist, dass die Aktualität von Repository und veröffentlichtem Artefakt auseinanderlaufen kann.

Was gemessen wurde – und worauf

Offizielle Referenz: GitHub repository API.

Jede Zahl hier wurde aus einer Live-API-Antwort zwischen 15:44 und 15:53 UTC am 2026-07-27 gelesen und zwischengespeichert. Der 35-zeilige Datensatz, die Repository-Liste, die gebauten Zeilen sowie die Fetch-/Build-Skripte in artifacts/ bewahren die Audit-Eingaben und die Transformationslogik.

Es wurden vier Datenkategorien erhoben; Registry- und Aktivitätsabfragen erfolgten bedarfsabhängig statt als starre Viererabfolge:

• GET /repos/{owner}/{repo} — Stars, archived, pushed_at, Lizenz, default_branch.
• GET /repos/{o}/{r}/commits?sha={default_branch}&per_page=1 — der neueste Commit auf dem Standard-Branch, als Signal für die Repository-Pflege.
• GET /repos/{o}/{r}/activity?per_page=30 — für jedes Repo, bei dem die beiden Zeitpunkte auseinanderlaufen, was pushed_at tatsächlich nach vorn gezogen hat.
• GET /repos/{o}/{r}/releases plus die PyPI- und npm-Registries — wann das Artefakt zuletzt veröffentlicht wurde; und genau das entpuppt sich als wichtiger als beides andere.

staleness_days ist die verstrichene Zeit vom Commit auf dem Standard-Branch bis zum Stichtag. Die Differenz zwischen pushed_at und diesem Commit ist die Illusion, gemessen in Tagen. Alles über 180 Tage wird markiert.

Zwei Punkte sind wichtig, weil sie das Ergebnis verändert haben.

Die Paketzuordnung wurde verifiziert, nie nur vermutet. Ein Paket, dessen README ein Repo erwähnt, ist noch nicht automatisch dieses Repo-Paket. Jede Zuordnung musste durch ein strukturiertes Feld bestätigt werden — den eigenen repository-/project_urls-Eintrag der Registry oder ein im Repo eingechecktes Manifest. Sechs plausibel aussehende Zuordnungen sind an diesem Test gescheitert; ihre Downloadzahlen werden bewusst nicht zugerechnet.

Eine dieser Ablehnungen ist den ganzen Grundsatz wert. curl-cffi zieht 35.763.529 Downloads pro Monat und wirkt aus der Distanz wie das Python-Binding zu lwthiker/curl-impersonate — einem Repo, das seit 875 Tagen kalt ist. Es darauf anzurechnen hätte eine Zahl ergeben, die 44-mal größer ist als die von newspaper3k, und sie wäre falsch gewesen: Die PyPI-Metadaten von curl-cffi verweisen auf lexiforest/curl_cffi, ein separates, aktiv gepflegtes Projekt, das zuletzt 2026-04-03 veröffentlicht wurde. Die spektakulärste Zahl hier war die falsche.

Ein siebter Fall ist noch merkwürdiger: steel-dev/steel-mcp-server deklariert in seiner eigenen package.json @steel-dev/mcp-server, aber npm liefert 404. Es wurde nie veröffentlicht, also kann „wird noch installiert“ hier überhaupt nicht zutreffen.

Wo keine Zahl ermittelbar war, wird das auch so benannt. Go-, JVM-, .NET- und PHP-Tools haben keine Präsenz auf PyPI oder npm und erhalten daher N/A (no PyPI/npm package) — niemals Null. Siebzehn der 35 haben überhaupt keine GitHub-Releases; das wird als none erfasst, nicht als fehlende Daten.

Diese Felder werden absichtlich nicht zu einem einzigen „Health Score“ zusammengezogen. Ein veralteter Standard-Branch, ein aktueller Nebenbranch, ein fehlendes GitHub-Release und ein altes Registry-Artefakt beantworten unterschiedliche Fragen. Die Belege auf Zeilenebene finden sich im 35-zeiligen Datensatz zusammen mit den Repository-Eingaben und gebauten Datensätzen. Lesen Sie sie als Triage-Signale, die den nächsten Prüfpunkt bestimmen — nicht als vier Stimmen darüber, ob ein Projekt lebt.

Die Sampling-Einschränkung gleich vorweg

Das hier ist eine handverlesene Liste von Tools, bei denen ich vermutete, dass sie von ihrem Ruf zehren. Es ist keine Zufallsstichprobe des Scraping-Ökosystems, und „31 von 35 sind veraltet“ ist keine Ökosystemrate — eher ein Maß dafür, wie gut ich ausgewählt habe. Das interessante Ergebnis ist nicht die Anzahl veralteter Repos. Interessant ist, dass selbst in einer Stichprobe, die für dieses Phänomen ausgewählt wurde, der konkrete Mechanismus, den ich geprüft habe, nur eine Minderheit der Fälle erklärt — und noch seltener positiv bestätigt werden konnte.

Die Illusion ist real — und hier ist der Extremfall

sjdirect/abot, ein .NET-Crawler mit 2.308 Stars. GitHub meldet einen Push am 2026-07-17, also zehn Tage vor dem Stichtag. Der Standard-Branch wurde zuletzt 2021-08-09 angetastet.

Das ist eine Lücke von 1.802 Tagen. Fünf Jahre. Der Header sagt: letzte Woche.

Vierzehn der 35 Repos zeigen eine Lücke von über 180 Tagen:

Vierzehn von 35. Reell, wichtig — und eine Minderheit einer Stichprobe, die genau dafür ausgewählt wurde.

Bei drei markierten Repos sind Bots bestätigt — und nach Filterung bleiben zwei übrig

Die gängige Erzählung nennt hier fast immer dependabot. Ich habe das überprüft, indem ich für jedes markierte Repo den Activity-Feed gezogen und jeden Ref klassifiziert habe, der nach dem letzten Commit auf dem Standard-Branch gepusht wurde. Dieses „nach“ ist entscheidend: Ereignisse vor dem letzten Commit sagen nichts darüber aus, was die Lücke vergrößert hat; wer den gesamten Feed mitzählt, ändert stillschweigend die Fragestellung.

Positiv bot-getrieben, nach der Post-Commit-Methode: drei. scrapinghub/splash (4 von 4 Post-Commit-Events auf dependabot/pip/*), geziyor/geziyor (5 von 5 auf dependabot/go_modules/*), apache/any23 (16 von 16 auf dependabot/maven/*). Einer dieser drei, any23, ist formell archiviert und fällt deshalb nie in den gefilterten Satz — übrig bleiben also zwei bestätigte Fälle, die zusätzlich alle anderen Bedingungen erfüllen.

Klar falsch: zwei, und beide sind interessanter als die Bot-Geschichte.

Die Lücke von 1.520 Tagen bei dragnet-org/dragnet stammt von einem Menschen, der einen Branch namens mp/py3.10 gepusht hat — ein nicht gemergter Python-3.10-Port. Jemand hat versucht, das Projekt voranzubringen, und dann aufgehört. Das ist kein automatisches Rauschen, das einen Zeitstempel künstlich aufbläst; das ist ein sichtbarer, datierter Eintrag eines gescheiterten Rettungsversuchs. Man kann argumentieren, dass genau das das nützlichste Signal im gesamten Datensatz ist — und das Narrativ „dependabot war’s“ hätte es ausgelöscht.

Gemischt und größer als beides: zwei. crawlab-team/crawlab hat 12.250 Stars — das zweit-meist-gestarbte Repo in der Stichprobe — und eine Lücke von 488 Tagen auf main. Im Feed finden sich dependabot-Branches und 24 Post-Commit-Pushes von Menschen, alle auf develop und test. Wer nur den Header liest, sieht Februar 2026 und hält das Projekt für gesund; wer nur main betrachtet, sieht Oktober 2024 und hält es für tot. Beides ist falsch. Die Entwicklung wurde vom Standard-Branch wegverlagert — etwas, das Projekte tun, das GitHubs Zusammenfassung aber nicht ausdrücken kann. sjdirect/abot ist der andere Mischfall: Der Push, der den hervorgehobenen pushed_at-Wert gesetzt hat, kam tatsächlich von dependabot; später pushte ein Mensch upgrade1 im Jahr 2024, weshalb das Repo im gefilterten Satz wieder herausfällt.

Rhizome-Conifer/conifer ist der ambivalente Fall, und ich habe ihn anfangs falsch gelesen. Sein Standard-Branch ist main, nicht master, und main hat sich seit 2023-10-12 nicht mehr bewegt — das einzige main-Event im Feed ist eine Branch-Erstellung im Januar 2025, also konsistent mit einer Umbenennung. Gleichzeitig hat ein einzelnes Konto am 2026-07-22 auf conifer-twilight und twilight/read-only gepusht, fünf Tage vor dem Stichtag. Das ist echte menschliche Aktivität, aber „aktiv weiterentwickelt“ ist stärker, als die Refs es hergeben: Ein Mitwirkender auf Branches mit dem Namen read-only passt mindestens genauso gut zu einem kontrollierten Auslaufen wie zu laufender Entwicklung. Was sich sagen lässt, ist enger und dennoch relevant: Die Lücke von 1.013 Tagen ist kein Bot-Rauschen — und auch kein Beweis für eine Aufgabe.

Unbekannt: sieben. php-html-parser, simhash-py, internetarchive/wayback, boilerpipe, waybackurls, wpull und crawler4j haben alle eine verifizierte Lücke, aber einen Activity-Feed, der leer zurückkommt.

Die naheliegende Erklärung wäre Retention — GitHubs Activity-Feed reicht nicht unendlich weit zurück. Der Cache widerlegt das für die meisten dieser Fälle. Das älteste Event in allen 123 Antworten liegt bei 2023-03-10, und fünf der sieben liegen mit pushed_at bequem innerhalb dieses Fensters: php-html-parser 2024-08-09, wpull 2024-04-29, waybackurls 2024-05-01, internetarchive/wayback 2024-03-01, simhash-py 2023-05-15. Was auch immer diese Zeitstempel verschoben hat, hätte im Feed auftauchen müssen — tat es aber nicht. Retention erklärt nur boilerpipe (2018) und crawler4j (2021).

Die ehrliche Aussage ist deshalb schmaler als eine hübsche Erklärung: Bei sieben Repos ist die Lücke ein verifizierter Fakt, ihre Ursache aber nicht geklärt — der Endpoint lieferte nichts, und bei fünf davon kann ich nicht sagen, warum. „Dependabot war’s“ ist für alle sieben nur eine Annahme.

Zusammengezählt über die 14 markierten Repos:

Die Zeilen summieren sich auf 14. Sie klassifizieren, was pushed_at bewegt hat; sie belegen nicht unabhängig, ob ein Projekt aufgegeben wurde.

Was nach dem vollständigen Filter übrig bleibt — und was „übrig bleibt“ überhaupt bedeutet

Die ursprüngliche Behauptung braucht vier Dinge gleichzeitig: über ein Jahr veraltet, pushed_at um mehr als 180 Tage aufgebläht, nicht archiviert und kein Hinweis darauf, dass die Aufblähung durch menschliche Arbeit verursacht wurde. Neun von 35 Kandidaten erfüllen alle vier Kriterien, hier neben den zwei wichtigsten Ausschlüssen:

Diese Zahl braucht eine Einschränkung, die der Filter selbst nicht ausdrücken kann. Nur zwei der neun — splash und geziyor — haben positive Evidenz dafür, dass Bots die Aufblähung verursacht haben. Die anderen sieben erfüllen die vierte Bedingung nur, weil es in keine Richtung Belege gibt. Sie sind Fälle, in denen die Behauptung bestehen bleibt, nicht Fälle, die sie bestätigen. Und die stärkste Bestätigung des gesamten Audits, any23 mit 16 von 16 dependabot-Events, fällt heraus, weil das Repo archiviert ist.

Beachten Sie außerdem: abot, der 1.802-Tage-Fall, gehört nicht zu den neun. Sein Datensatz enthält einen menschlichen Push, also fällt er an der vierten Bedingung durch — die dramatischste Illusion im Datensatz ist gerade kein sauberer Fall des Mechanismus, den sie illustriert.

Bei 21 von 35 hat GitHub die Veraltung ganz offen gezeigt

Hier ist der Befund, der meine These am stärksten beschädigt hat. Vierzehn Repos haben eine Lücke von genau null, und sieben weitere liegen unter 180 Tagen. Bei 21 von 35 Kandidaten ist pushed_at also tatsächlich der letzte Commit auf dem Standard-Branch. GitHub verschleiert nichts.

Und das sogar bei einigen der totesten Dinge in der Stichprobe:

BuilderIO/gpt-crawler hat 22.374 Stars, und sein Header sagt seit 2025-07-07 dasselbe. Nichts ist verborgen, und die Installationszahlen laufen weiter.

Damit reduziert sich die Behauptung auf etwas Engeres: GitHub verschleiert Veraltung nur in einer Minderheit der Fälle, und in der Mehrheit benennt es sie offen, während die Installationen trotzdem weiterlaufen. Warum sie weiterlaufen, kann diese Datenlage nicht beantworten — hier werden Installationen gezählt, nicht Entscheidungen. Aber ein UI-Change löst den zweiten, größeren Teil nicht.

Repository-Aktivität und veröffentlichte Artefakte können auseinanderlaufen

Die auffälligste Zeile im Datensatz sprengt den Rahmen komplett.

codelucas/newspaper — 15.126 Stars — ist aktiv. Sein letzter Commit auf dem Standard-Branch ist auf 2026-07-21 datiert, bei einem Stichtag 2026-07-27, und wurde vom Maintainer selbst geschrieben. Jeder Check auf Repo-Ebene besteht.

Das Paket, das alle installieren, ist newspaper3k 0.2.8, veröffentlicht am 2018-09-28. Das ist 2.858 Tage alt, und es zieht 813.513 Downloads pro Monat.

Der Standard-Branch ist aktuell, während das PyPI-Artefakt seit 2018 nicht mehr veröffentlicht wurde. Das beweist eine Release-Lücke — aber nicht, warum das Paket nicht mehr veröffentlicht wurde oder ob eine Pipeline defekt ist. Genau das ist die Art von Risiko, die ein reiner Repository-Check übersehen würde, denn das Registry-Artefakt ist das, was nach pip install newspaper3k normalerweise tatsächlich läuft.

Sobald man statt Repos auf Pakete schaut, taucht das Muster überall auf. Unter den 17 Paketen, deren Repo-Zuordnung verifiziert wurde, wurden 16 zuletzt vor mehr als einem Jahr veröffentlicht, und diese 16 stehen für rund 2,28 Millionen Installationen pro Monat von insgesamt 2,30 Millionen:

tls-client verdient eine eigene Zeile: 790.305 Installationen pro Monat aus einem Repo, das seit 905 Tagen kalt ist — in einer Kategorie, in der aktuell zu bleiben die eigentliche Aufgabe ist. Das TLS-Verhalten von Browsern ändert sich; eine Bibliothek, die das seit Anfang 2024 nicht mehr nachverfolgt, arbeitet mit Annahmen von Anfang 2024.

Zwei Hinweise zu dieser Tabelle: Registry-Downloadzahlen enthalten auch CI-Läufe und Mirrors und deduplizieren nichts — sie messen Installationsvolumen, nicht Menschen. Und die rollierenden Zeitfenster haben nicht dasselbe Enddatum — npm endet nahe 2026-07-24, pypistats bezieht sich auf den Abrufzeitpunkt — deshalb ist die Summe leicht versetzt und sollte als „etwa 2,28 Millionen“ gelesen werden, nicht als exakte Ziffer.

Die Namenskollision, die man kennen sollte

internetarchive/wayback ist das tote Java-OpenWayback, seit 1.916 Tagen kalt. wayback auf PyPI ist ein völlig anderes Projekt — edgi-govdata-archiving/wayback — und es ist gesund; Version 0.5.1 wurde am 2026-06-19 veröffentlicht, also fünf Wochen vor dem Stichtag. Gleicher Name, gegenteilige Lage, kein Zusammenhang. Das war eine der sechs abgelehnten Zuordnungen, und es ist die, die einem echten Nutzer am ehesten auf die Füße fallen kann: Bei der Namenssuche bekommen Sie beide, und auf keiner Seite steht, welches Projekt Sie eigentlich gefunden haben.

Archiviert, deprecated — und trotzdem 127.232-mal pro Monat installiert

Sechs Repos in der Stichprobe tragen archived: true, was GitHub als Banner über die volle Breite darstellt. Meine erste Lesart war: Das beweist, dass Leute Warnungen ignorieren. Der Cache zeigt, dass die Geschichte schlimmer ist.

Offizielle Referenz: npm download-count API documentation.

Offizielle Referenz: npm's deprecation documentation.

@modelcontextprotocol/server-puppeteer kommt auf 127.232 Installationen pro Monat aus modelcontextprotocol/servers-archived. Aber das npm-Feld repository ist null — es gibt also keinen Link von der Paketseite zurück zum Repo, sodass das Banner nicht einfach übersehen werden konnte. Die meisten, die dieses Paket installieren, hatten gar keinen Weg zum Repo.

Was npm tatsächlich ausliefert, ist die Deprecation. Die neueste Version des Pakets enthält deprecated: "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." — und npm schreibt das bei der Installation in die Konsole. Die Warnung wird also genau dort angezeigt, wo der Nutzer sich befindet, und trotzdem laufen 127.232 Installationen pro Monat weiter. Das ist ein stärkerer Befund als der Banner allein, und er zeigt in eine andere Richtung: Das Signal fehlt nicht — es geht nur in einem Strom von Installationsausgabe unter, den niemand lesen muss.

browserbase/mcp-server-browserbase zeigt, wie ein sauberer Shutdown aussieht: Sein letzter Commit auf dem Standard-Branch, am 2026-07-20, lautet wörtlich „Mark repository as archived and unmaintained (#198)“. Die Maintainer haben es angekündigt, datiert und in der API markiert. Seine 20.389 Installationen sollte man dennoch genau lesen — das npm-Fenster reicht von 2026-06-25 bis 2026-07-24, also liegen 26 dieser 30 Tage vor dem Archiv-Commit. Diese Zahl ist also vor allem Nachfrage vor der Ankündigung, nicht Trotz danach. Was anschließend passiert, lässt sich aus diesem Snapshot wirklich nicht sagen, und ich würde in einem Monat noch einmal prüfen, bevor ich etwas behaupte.

57 Stars, 204.025 Installationen pro Monat

Janpot/microdata-node hat 57 Stars und zieht 204.025 Downloads pro Monat aus einem Release vom 2020-05-11.

Mit 57 Stars hat microdata-node im Verhältnis zu seinem Registry-Volumen nur geringe Sichtbarkeit im Repository. Das Verhältnis von 3.579 Installationen pro Star passt zu transiviver Nutzung, wiederholten CI-Läufen, Mirrors oder direkter maschineller Nutzung. Dieser Audit hat keine Abhängigkeitsgraphen abgerufen und kann zwischen diesen Erklärungen nicht unterscheiden.

Die Zeile ist ein Hinweis darauf, indirekte Exponierung zu inventarisieren — aber transitive Nutzung lässt sich nur mit Reverse-Dependency- oder Lockfile-Belegen nachweisen, die dieser Audit nicht erhoben hat.

Veraltet ist nicht dasselbe wie kaputt

Ein ehrlicher Audit muss das sagen: Davon wird nicht gemessen, ob etwas kaputt ist. Gemessen wird, ob noch jemand da ist.

Manches ist einfach fertig. SetSimilaritySearch implementiert Algorithmen für Set-Similarity; die werden nicht „schlecht“. simhash basiert auf einem Paper von 2007. boilerpipes Content-Extraktionsalgorithmus verhält sich 2026 genauso wie 2015 — unabhängig davon, wie gut er mit modernen Seiten zurechtkommt, der Code ist Ihnen nicht unter den Füßen weggewandert.

Verrottet ist alles, was auf der anderen Seite einen beweglichen Zielpunkt hat:

• Browser-Automatisierung — jede Chrome-Version kann sie brechen.
• HTTP-Client-Verhalten, das echte Browser nachahmt — Browser ändern sich, und eine eingefrorene Bibliothek passt nicht mehr; tls-client fällt genau hier hinein.
• Seiten-spezifische Parser und Extraktionsregeln pro Website — jedes Redesign ist ein Bug.
• Alles, was eine Drittanbieter-API umhüllt — der Anbieter ändert das Schema, und Sie merken es erst in Produktion.
• Alles, was ein LLM umhüllt — Modell-Abkündigungen sind schneller als all das hier.

Also ist „1.606 Tage alt“ für eine Kategorie ein Alarmfall und für ein Hashing-Utility fast irrelevant. Ein Breakage-Test wurde hier nicht durchgeführt, und es wird auch kein Anspruch darauf erhoben; Ihre eigenen Abhängigkeiten danach zu sortieren, in welche Kategorie sie fallen, kostet nichts und bringt mehr als die Veraltungszahl allein.

Die vier Checks, die die Frage wirklich beantworten

Keiner davon ist der Repo-Header.

Führen Sie die Checks 1, 2 und 3 als schnelle Triage aus. Eskalieren Sie dann, wenn Repository-Metadaten fehlen, die Paketzuordnung unklar ist, Aktivität auf einen Nicht-Standard-Branch gewandert ist oder sich das Registry-Artefakt vom Repository unterscheidet. Unauthentifizierte GitHub-Limits und Registry-Latenz machen ein Versprechen von einer Sekunde unvernünftig.

Wenn ein Check etwas Kaltes in einer beweglichen Kategorie findet, sind die gepflegten Alternativen in diesem Bereich aus unseren eigenen Tests dokumentiert: Trafilatura für die Content-Extraktion, die dragnet und boilerpipe früher erledigt haben, Scrapy oder Crawlee für Crawling-Frameworks, Crawl4AI und Firecrawl für LLM-orientierte Extraktion sowie Scrapling, wenn Robustheit zählt. Unser Open-Source-Scraper-Pillar deckt die breitere Auswahl ab. Das sind First-Party-Reviews; führen Sie die vier Checks selbst aus, bevor Sie irgendeiner Empfehlung vertrauen — auch unserer.

Grenzen dieser Daten

• Stichprobenauswahl. Handverlesen wegen vermuteter Aufgabe. Daraus lassen sich keine Ökosystemraten ableiten.
• Kein Breakage-Test. Keines dieser 35 Tools wurde gegen eine Live-Seite ausgeführt. Veraltung ist ein Wartungssignal, kein Funktionsurteil.
• Downloadzahlen enthalten Maschinen. CI, Mirrors, keine Deduplizierung und Fenster ohne gemeinsames Enddatum. Installationsvolumen, nicht Nutzer, und nicht Entscheidungen.
• Sieben unbekannte Ursachen bleiben unbekannt. Der Activity-Feed lieferte nichts, und bei fünf der sieben erklärt Retention das nicht. Eine leere Zelle ist besser als die übliche Vermutung.
• staleness_days verwendet Committer-Daten. Umschriebene oder rückdatierte Historie würde das verzerren. Nichts davon wurde erkannt — was nicht dasselbe ist wie „existiert nicht“.
• Ein Stichtag. 2026-07-27. Mehrere dieser Repos werden sich bis zu Ihrer Lektüre bewegt haben — newspaper vor allem commitet regelmäßig. Führen Sie die vier Checks erneut aus; zitieren Sie nicht meine Daten.

Wo ein Managed Service die Lage verändert

Jeder Check hier existiert, weil Sie bei einer selbst gehosteten Bibliothek die Veraltung selbst tragen. Wenn ein eingefrorener HTTP-Client sich nicht mehr wie ein aktueller Browser verhält, ist das Ihr Vorfall — zu welcher Uhrzeit auch immer er auftaucht.

Autorennotiz: Thunderbit ist unser Managed-Scraping-Produkt. Ein Managed Service verlagert einen Teil der Wartungsverantwortung zum Anbieter, aber Abdeckung, Reaktionszeit, Lock-in und die Kontinuität des Anbieters werden Teil des Risikomodells. Thunderbit wurde in diesem Repository-Audit nicht bewertet.

Der ehrliche Tausch: Sie verlieren die Möglichkeit, den Quellcode zu lesen, eine Version festzupinnen und nachts um zwei selbst zu fixen. Für Teams, die ohnehin Scraper betreiben und pflegen, ist Open Source oft die richtige Wahl — und genau die vier Checks machen daraus eine Entscheidung statt einer Annahme.

Thunderbit für Web-Datenextraktion testen

Kurzfassung

Ich habe eine Liste gebaut, um zu beweisen, dass GitHub Aufgabe verschleiert. Die Illusion ist bei 14 von 35 Repos real und in einem Fall spektakulär: sjdirect/abot zeigt einen Push von letzter Woche gegen einen seit 2021 eingefrorenen Standard-Branch — eine Lücke von 1.802 Tagen.

Aber der Mechanismus ist enger als die Geschichte. Neun Repos erfüllen alle vier Bedingungen, die die Behauptung verlangt, und nur zwei dieser neun — splash und geziyor — haben positive Belege dafür, dass Bots die Aufblähung verursacht haben; der Rest besteht die Hürde durch fehlende Beweise. Zwei markierte Repos sind Menschen, die ein Projekt wiederzubeleben versuchen und scheitern. Eines, crawlab, hat 12.250 Stars und hat die Entwicklung einfach auf develop verlagert. Bei sieben kam der Activity-Feed leer zurück, und Retention erklärt fünf davon nicht, also ist die Ursache nicht belegt, sondern nur vermutet. Und bei 21 von 35 hat GitHub die Veraltung korrekt angezeigt.

Der schlimmste Fall im Datensatz besteht jeden Repo-Check. codelucas/newspaper wurde am 2026-07-21 committet; newspaper3k, zuletzt am 2018-09-28 veröffentlicht, wurde in diesem Monat 813.513-mal ausgeliefert. Über die Stichprobe hinweg entfallen auf 16 Pakete mit Releases, die älter als ein Jahr sind, rund 2,28 Millionen Installationen pro Monat.

Prüfen Sie als erste Triage den Commit auf dem Standard-Branch, das Veröffentlichungsdatum des Registry-Artefakts, das archived-Flag und das npm-Deprecation-Feld. Klären Sie die Paket-zu-Repository-Zuordnung und die Entwicklung auf Nicht-Standard-Branches, bevor Sie ein Fazit ziehen.

Thunderbit für Web-Datenextraktion testen Get Started Free

FAQs

Was ist pushed_at und warum bedeutet es nicht „zuletzt aktualisiert“?
pushed_at ist das GitHub-API-Feld hinter dem Aktivitätszeitstempel auf der Repository-Seite, und es aktualisiert sich, wenn auf irgendeinen Branch gepusht wird. Der neueste Commit auf dem Standard-Branch ist nur ein Wartungssignal für das Repo; Paketmanager installieren normalerweise Registry-Artefakte oder aufgelöste Modulversionen. In diesem Audit lagen bei 14 von 35 Repos diese beiden GitHub-Daten mehr als 180 Tage auseinander.

Ist das immer dependabot, der diesen Zeitstempel aufbläht?
Nein, und genau das war der schwächste Teil der üblichen Geschichte. Zählt man nur Ereignisse, die nach dem letzten Commit auf dem Standard-Branch liegen, sind Bots in 3 der 14 markierten Repos bestätigt (splash 4 von 4, geziyor 5 von 5, any23 16 von 16). Bei 2 ist die Erklärung schlicht falsch: Die Lücke bei dragnet stammt von einem Menschen, der einen nicht gemergten Python-3.10-Port gepusht hat. Zwei weitere sind gemischt, darunter crawlab, wo 24 menschliche Pushes auf develop und test gingen, während main stillstand. Und bei 7 lieferte der Activity-Feed gar nichts zurück, also ist die Ursache nicht belegt — Retention erklärt nur zwei dieser sieben.

Heißt ein veraltetes Repo automatisch, dass das Tool kaputt ist?
Nein — darauf gibt es hier keinen Beleg, denn nichts wurde gegen eine Live-Seite ausgeführt. Veraltung ist je nach Zielkategorie unterschiedlich relevant: Browser-Automatisierung, HTTP-Clients, die Browserverhalten nachahmen, seiten-spezifische Parser und API-/LLM-Wrapper altern schnell, während algorithmische Bibliotheken wie SetSimilaritySearch oder simhash auch nach Jahren noch völlig in Ordnung sein können. tls-client ist der schärfste Fall in der Stichprobe: 790.305 Installationen pro Monat aus einem Repo, das seit 905 Tagen kalt ist.

Wie kann ein Repo aktiv sein, aber das Paket trotzdem tot?
Das ist codelucas/newspaper, und es ist der wichtigste Befund dieses Audits. Der Standard-Branch wurde am 2026-07-21 committet, also Tage vor dem Stichtag, aber newspaper3k auf PyPI wurde zuletzt 0.2.8 am 2018-09-28 veröffentlicht — vor 2.858 Tagen — und wird trotzdem 813.513-mal pro Monat heruntergeladen. Repo-Checks bestehen alle; das Artefakt, das Sie installieren, ist acht Jahre alt. Prüfen Sie immer das letzte Veröffentlichungsdatum der Registry getrennt vom Commit-Log.

Lösen archivierte Repos das Problem? GitHub zeigt doch ein Banner.
Nicht zuverlässig, und @modelcontextprotocol/server-puppeteer zeigt warum. Das npm-Feld repository ist null, es gibt also keinen Link vom Paket zum archivierten Repo und kein Banner, das man „überspringen“ könnte. Was npm liefert, ist der deprecated-String des Pakets — „Package no longer supported“ — der bei der Installation ausgegeben wird, und trotzdem laufen 127.232 Installationen pro Monat weiter. browserbase/mcp-server-browserbase hat seine Abschaltung im letzten Commit korrekt angekündigt; die 20.389 Installationen liegen größtenteils vor diesem Commit und sagen deshalb in die eine wie in die andere Richtung wenig aus.

Wie prüfe ich meine eigenen Abhängigkeiten schnell?
Beginnen Sie mit dem Commit-Datum des Standard-Branches, dem Release-/Upload-Datum der Registry, dem npm-Deprecation-Feld und dem archived-Flag des Repos. Danach verifizieren Sie die Zuordnung Paket ↔ Repository, schauen bei abweichender Aktivität auf Nicht-Standard-Branches und nutzen Abhängigkeitsgraphen oder Lockfiles, bevor Sie von transiver Exposition sprechen. Namensüberschneidungen wie die völlig unabhängigen Java- und PyPI-Projekte wayback machen diese Eskalation notwendig.