GitHub `pushed_at` zkreslil stav u 14 z 35 scraping repozitářů; u tří byly potvrzeny boty

Na stránce repozitáře GitHub zobrazuje pushed_at, tedy časovou značku, která se může změnit pokaždé, když se do libovolné větve pošle push. To se ale může lišit od data nejnovějšího commitu na výchozí větvi. Datum výchozí větve je signál o údržbě repozitáře; neznamená nutně, že jde o kód, který vám nainstaluje správce balíčků.

Správci balíčků obvykle načítají artefakty z registru nebo konkrétní verze modulů. Právě proto tato analýza odděleně sleduje aktivitu repozitáře a zveřejněný artefakt: jedno může být čerstvé, zatímco druhé už je dávno zastaralé.

Vybral jsem proto 35 repozitářů, které se pořád objevují v doporučeních, a podíval se na údaj, který GitHub do hlavičky vůbec nedává: datum nejnovějšího commitu na výchozí větvi.

Rozdíl je skutečný: u 14 z 35 repozitářů je pushed_at o víc než 180 dní před posledním commitem na výchozí větvi, přičemž maximum dosahuje 1 802 dní. U tří z těchto 14 byly boty potvrzeny bez pochyb; po započtení archivovaných projektů a filtrů lidské aktivity zůstávají mezi devíti kandidáty dva potvrzené případy botů. Nejpodstatnější zjištění ale je, že čerstvost repozitáře a čerstvost publikovaného artefaktu se mohou rozcházet.

Co se měřilo a na čem

Oficiální reference: GitHub repository API.

Všechny zde uvedené údaje byly načteny z live API odpovědí mezi 15:44 a 15:53 UTC dne 2026-07-27 a následně uloženy do mezipaměti. Dataset o 35 řádcích, seznam repozitářů, vygenerované řádky a skripty pro načítání a zpracování v artifacts/ uchovávají vstupy auditu i transformační logiku.

Sbíraly se čtyři datové kategorie; požadavky na registry a aktivitu nebyly jednou jednotnou čtyřkrokovou sekvencí, ale podle potřeby:

• GET /repos/{owner}/{repo} — hvězdičky, archived, pushed_at, licence, default_branch.
• GET /repos/{o}/{r}/commits?sha={default_branch}&per_page=1 — nejnovější commit na výchozí větvi, použitý jako signál údržby repozitáře.
• GET /repos/{o}/{r}/activity?per_page=30 — u každého repozitáře, kde se tyto dva údaje rozcházely, co přesně pushed_at posunulo.
• GET /repos/{o}/{r}/releases plus registry PyPI a npm — kdy byl naposledy vydán artefakt, což se nakonec ukázalo jako důležitější než obojí předchozí.

staleness_days je uplynulý čas od commitu na výchozí větvi k okamžiku měření. Rozdíl mezi pushed_at a tímto commitem je onen klam, měřený ve dnech. Všechno nad 180 dní je označeno.

Důležité jsou ještě dvě metodická pravidla, protože právě ta změnila výsledky.

Přiřazení balíčku bylo vždy ověřeno, nikdy neodhadováno. Balíček, jehož README zmiňuje repozitář, není automaticky balíčkem daného repozitáře. Každé propojení muselo být potvrzeno strukturovaným údajem — buď vlastním polem repository/project_urls v registru, nebo manifestem uloženým přímo v repozitáři. Šest zdánlivě přesvědčivých vazeb tímto testem neprošlo a jejich downloady záměrně nejsou připsány.

Jeden z těchto vyřazených případů stojí za celé pravidlo. curl-cffi má 35 763 529 stažení měsíčně a z dálky vypadá jako Python binding pro lwthiker/curl-impersonate — repozitář, který je studený už 875 dní. Kdybychom mu toto přiřazení připsali, dostali bychom číslo čtyřiačtyřicetkrát vyšší než u newspaper3k, a bylo by to nepravdivé: metadata PyPI pro curl-cffi ukazují na lexiforest/curl_cffi, samostatný a aktivně udržovaný projekt, který byl naposledy vydán 2026-04-03. Nejokázalejší číslo bylo tady zároveň to špatné.

Sedmý případ je ještě zvláštnější: steel-dev/steel-mcp-server uvádí ve vlastním package.json @steel-dev/mcp-server, ale npm vrací 404. Nikdy nebyl publikován, takže o něm nelze říct, že je „stále instalován“.

Kde číslo nešlo získat, je to výslovně uvedeno. Nástroje pro Go, JVM, .NET a PHP nemají přítomnost na PyPI ani npm, a proto mají uvedeno N/A (no PyPI/npm package) — nikdy nulu. Sedmnáct z 35 repozitářů nemá žádné GitHub Releases; to je zaznamenáno jako none, ne jako chybějící data.

Tyto položky nejsou záměrně sloučené do jediného „health score“. Zastaralá výchozí větev, čerstvá vedlejší větev, chybějící GitHub Release a starý registr artefakt odpovídají na různé otázky. Důkazy na úrovni řádků jsou v datasetu o 35 řádcích spolu s vstupy repozitářů a vygenerovanými záznamy. Čtěte je jako triážní signály, které určují další kontrolu, ne jako čtyři hlasy o tom, zda je projekt živý.

Hned na začátku poznámka k výběru vzorku

Jde o ručně sestavený seznam nástrojů, u nichž jsem měl podezření, že jedou jen z reputace. Nejde o náhodný vzorek scraping ekosystému a tvrzení „31 z 35 jsou zastaralé“ není míra celého ekosystému — je to spíš odraz toho, jak dobře jsem ten vzorek vybral. Zajímavý výsledek není samotný počet zastaralých projektů. Zajímavé je, že i ve vzorku vybraném kvůli tomuto jevu vysvětloval testovaný mechanismus jen menšinu případů a u ještě menší části se dal pozitivně potvrdit.

Iluze je reálná a tady je její nejhorší případ

sjdirect/abot, .NET crawler s 2 308 hvězdičkami. GitHub u něj hlásí push z 2026-07-17, tedy deset dní před datem měření. Výchozí větev byla naposledy upravena 2021-08-09.

To je rozdíl 1 802 dní. Pět let. V hlavičce ale svítí minulý týden.

U 14 z 35 repozitářů je rozdíl větší než 180 dní:

Čtrnáct z pětatřiceti. Je to reálné, stojí za to to vědět, a přesto jde jen o menšinu vzorku vybraného právě kvůli tomuto jevu.

Boty jsou potvrzeny u tří označených repozitářů — a po filtrování zůstávají dva

Lidová verze toho příběhu vždycky zmiňuje dependabot. Ověřil jsem to tak, že jsem stáhl activity feed každého označeného repozitáře a klasifikoval každý ref pushnutý po posledním commitu na výchozí větvi. To „po“ je zásadní: události starší než poslední commit neříkají nic o tom, co nafouklo rozdíl, a počítání celého feedu potichu mění otázku.

Potvrzeně botí původ, při metodě po commitu: tři. scrapinghub/splash (4 ze 4 post-commit událostí na dependabot/pip/*), geziyor/geziyor (5 z 5 na dependabot/go_modules/*), apache/any23 (16 z 16 na dependabot/maven/*). Jeden z těchto tří, any23, je oficiálně archivovaný, takže se nikdy nedostane do filtrované množiny — zůstávají tedy dva potvrzené případy, které splňují i všechny ostatní podmínky.

Jednoznačně špatně: dvě, a obě jsou zajímavější než samotný botí příběh.

Rozdíl 1 520 dní u dragnet-org/dragnet vznikl tím, že člověk pushnul větev mp/py3.10 — nepropojený port na Python 3.10. Někdo se pokusil projekt posunout dál a pak přestal. To není automatický hluk nafukující časovou značku; je to viditelný, datovaný záznam o pokusu o záchranu, který nevyšel. Dá se tvrdit, že je to vůbec nejužitečnější signál v celém datasetu, a rámování typu „udělal to dependabot“ by ho smazalo.

Smíšené, a větší než obojí: dvě. crawlab-team/crawlab má 12 250 hvězdiček — druhý nejvyšší počet ve vzorku — a na main má rozdíl 488 dní. Ve feedu jsou větve dependabotu i 24 post-commit pushů od lidí, všechny na develop a test. Uživatel, který se podívá jen na hlavičku, vidí únor 2026 a myslí si, že projekt žije; uživatel, který sleduje jen main, vidí říjen 2024 a myslí si, že je mrtvý. Obojí je špatně. Vývoj se přesunul mimo výchozí větev, což projekty běžně dělají a GitHub to v souhrnném pohledu neumí vyjádřit. sjdirect/abot je další smíšený případ: push, který nastavil jeho hlavní pushed_at, byl skutečně od dependabotu, ale člověk v roce 2024 pushnul upgrade1, a proto později vypadne z filtrované množiny.

Rhizome-Conifer/conifer je nejednoznačný případ a zpočátku jsem ho vyhodnotil špatně. Jeho výchozí větev je main, ne master, a main je nehybná od 2023-10-12 — jediná událost na main ve feedu je vytvoření větve v lednu 2025, což odpovídá přejmenování. Mezitím jeden účet pushoval na conifer-twilight a twilight/read-only dne 2026-07-22, tedy pět dní před datem měření. To je skutečná lidská aktivita, ale „aktivně vyvíjený“ je silnější tvrzení, než co dovolují samotné refy: jeden přispěvatel na větvích s názvy read-only je stejně dobře slučitelný s řízeným útlumem jako s pokračujícím vývojem. Co lze říct, je užší, ale stále podstatné: rozdíl 1 013 dní není botí šum, ale také to samo o sobě není důkaz opuštění.

Neznámé: sedm. php-html-parser, simhash-py, internetarchive/wayback, boilerpipe, waybackurls, wpull a crawler4j mají ověřený rozdíl a activity feed, který se vrací prázdný.

Lákavé vysvětlení je retence — activity feed GitHubu nesahá do nekonečna. Cache to u většiny případů vyvrací. Nejstarší událost v těchto 123 odpovědích je 2023-03-10 a pět ze sedmi má pushed_at pohodlně uvnitř tohoto okna: php-html-parser 2024-08-09, wpull 2024-04-29, waybackurls 2024-05-01, internetarchive/wayback 2024-03-01, simhash-py 2023-05-15. Cokoli tyto časové značky posunulo, mělo být ve feedu a nebylo. Retence vysvětluje jen boilerpipe (2018) a crawler4j (2021).

Poctivé tvrzení je tedy skromnější než uhlazené vysvětlení: u sedmi repozitářů je rozdíl ověřený fakt a jeho příčina není prokázána — endpoint nic nevrátil, a u pěti z nich nevím proč. „Udělal to dependabot“ je u všech sedmi jen domněnka.

Po sečtení u 14 označených repozitářů:

Řádky dávají součet 14. Klasifikují, co posunulo pushed_at; samy o sobě ale neprokazují, zda je projekt opuštěný.

Co přežije celý filtr a co znamená „přežije“

Původní tvrzení potřebuje současně čtyři věci: zastaralost delší než rok, pushed_at nafouknuté o více než 180 dní, nearchivovaný stav a žádný náznak, že nafouknutí způsobila lidská práce. Devět z 35 kandidátů projde všemi čtyřmi podmínkami, zde uvedených spolu se dvěma nejdůležitějšími výjimkami:

To číslo ale potřebuje dovětek, který filtr neumí nést. Pouze dva z těch devíti — splash a geziyor — mají pozitivní důkaz, že nafouknutí způsobili boti. Zbývajících sedm splňuje čtvrtou podmínku tím, že pro ni není žádný důkaz ani jedním směrem. Jsou to případy, které tvrzení přežije, ne případy, které ho potvrzují. A nejsilnější potvrzení v celém auditu, any23 se 16 ze 16 dependabot událostí, je vyřazeno, protože repozitář je archivovaný.

Všimněte si také, že abot, tedy případ s rozdílem 1 802 dní, mezi těmi devíti není. V záznamech má lidský push, takže čtvrtou podmínku nesplňuje — nejdramatičtější iluze v datasetu tedy není čistým příkladem mechanismu, který ilustruje.

U 21 z 35 GitHub stálost ukázal úplně otevřeně

Tady je zjištění, které nejvíc poškodilo mou původní tezi. U 14 repozitářů je rozdíl přesně nula a dalších sedm je pod hranicí 180 dní. U 21 z 35 kandidátů je pushed_at skutečně posledním commitem na výchozí větvi. GitHub nic neskrývá.

Včetně některých z nejstarších položek ve vzorku:

BuilderIO/gpt-crawler má 22 374 hvězdiček a jeho hlavička říká totéž už od 2025-07-07. Nic není skryto a počet instalací dál roste.

To posouvá tvrzení na užší úroveň: GitHub stálost v menšině případů zamlžuje, ale ve většině ji ukazuje otevřeně, zatímco instalace pokračují stejně. Proč pokračují, z těchto dat určit nelze — čísla zde měří instalace, ne rozhodnutí. Ale změna UI neřeší druhou skupinu, která je větší.

Aktivita repozitáře a publikované artefakty se mohou rozcházet

Jediný nejvýraznější řádek v datasetu rozbíjí celé rámování.

codelucas/newspaper — 15 126 hvězdiček — je aktivní. Poslední commit na výchozí větvi je datován 2026-07-21, tedy vůči dni měření 2026-07-27, a byl napsán správcem projektu. Všechny kontroly na úrovni repozitáře procházejí.

Balíček, který si všichni instalují, je newspaper3k 0.2.8, vydaný 2018-09-28. To je 2 858 dní starý artefakt a má 813 513 stažení měsíčně.

Výchozí větev je aktuální, zatímco artefakt na PyPI nebyl vydán od roku 2018. To dokazuje mezeru ve vydávání, ne proč k ní došlo ani zda je rozbitý build pipeline. Je to přesně ten typ rizika, který by kontrola pouze repozitáře minula, protože právě registry artefakt je to, co se obvykle spouští po pip install newspaper3k.

Jakmile se podíváte na balíčky místo repozitářů, vzorec je všude. Ze 17 balíčků, u nichž bylo přiřazení k repozitáři ověřeno, jich 16 vydalo poslední verzi před více než rokem, a těchto 16 dohromady tvoří přibližně 2,28 milionu instalací měsíčně z celkových 2,30 milionu:

tls-client si zaslouží vlastní řádek: 790 305 instalací měsíčně z repozitáře, který je chladný už 905 dní, v kategorii, kde je držet krok s vývojem celá práce. Chování TLS v prohlížečích se mění; knihovna, která ho přestala sledovat na začátku roku 2024, běží na předpokladech z počátku roku 2024.

Dvě poznámky k této tabulce. Počty stažení z registrů zahrnují CI běhy i zrcadla a nic nede-duplikují, takže měří objem instalací, ne počet lidí. A posuvná okna nemají stejný konec — u npm je to blízko 2026-07-24, u pypistats relativně vůči času načtení — takže celkový součet je součtem lehce posunutých měsíců a měl by být čten jako „asi 2,28 milionu“, ne na jednotky.

Název, na který je dobré si dát pozor

internetarchive/wayback je mrtvý Java OpenWayback, studený už 1 916 dní. wayback na PyPI je úplně jiný projekt — edgi-govdata-archiving/wayback — a je v dobré kondici; vydal verzi 0.5.1 dne 2026-06-19, tedy pět týdnů před datem měření. Stejný název, opačný stav, žádná souvislost. To byl jeden ze šesti odmítnutých odhadů přiřazení a zároveň ten, který nejspíš nejvíc mate běžného uživatele: hledání podle názvu vrátí oba projekty a na žádné stránce není napsáno, který z nich jste našli.

Archivovaný, označený jako deprecated a přesto stále instalovaný 127 232krát měsíčně

Šest repozitářů ve vzorku má archived: true, které GitHub vykresluje jako široký banner přes celou šířku stránky. První dojem byl, že to dokazuje, jak lidé ignorují hlasitá varování. Cache ale ukazuje, že příběh je horší.

Oficiální reference: npm download-count API documentation.

Oficiální reference: npm's deprecation documentation.

@modelcontextprotocol/server-puppeteer má 127 232 instalací měsíčně z modelcontextprotocol/servers-archived. Jeho npm pole repository je ale null — z balíčku nevede žádný odkaz zpátky na repozitář, takže banner není něco, co by instalátor mohl jednoduše přeskočit. Většina lidí, kteří balíček stahují, se k němu ani nedostane přes stránku repozitáře.

Co npm skutečně publikuje, je deprecation. Nejnovější verze balíčku nese text deprecated: "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." — a npm ho při instalaci vypisuje do terminálu. Varování tedy dorazí přesně tam, kde uživatel je, a přesto 127 232 instalací měsíčně pokračuje dál. To je silnější zjištění než samotný banner a ukazuje jinam: signál nechybí, ale přichází uprostřed instalčního výstupu, který nikdo nemusí číst.

browserbase/mcp-server-browserbase ukazuje, jak vypadá čisté ukončení: jeho poslední commit na výchozí větvi z 2026-07-20 se doslova jmenuje "Mark repository as archived and unmaintained (#198)". Správci projekt oznámili, datovali a označili v API. Jeho 20 389 instalací ale stojí za pečlivé čtení — npm okno běží od 2026-06-25 do 2026-07-24, takže 26 z těchto 30 dnů předchází commitu o archivaci. Tahle čísla jsou tedy převážně poptávka před oznámením, ne odpor proti němu. Co bude dál, z tohoto snímku opravdu nevíme, a než bych tvrdil cokoli dalšího, chtěl bych za měsíc znovu provést měření.

57 hvězdiček, 204 025 instalací měsíčně

Janpot/microdata-node má 57 hvězdiček a čerpá 204 025 stažení měsíčně z releasu datovaného 2020-05-11.

S 57 hvězdičkami má microdata-node ve srovnání s objemem v registru velmi malou viditelnost. Poměr instalací ke hvězdičkám 3 579 : 1 odpovídá nepřímému používání, opakovaným CI běhům, zrcadlům nebo přímé strojové spotřebě. Tato analýza nestáhla žádné dependency grafy, a proto mezi těmito vysvětleními nemůže vybírat.

Řádek je výzvou k inventarizaci nepřímé expozice, ale prokázat transitivní použití by vyžadovalo důkazy z reverse-dependency nebo lockfile, které tento audit nesbíral.

Zastaralé neznamená rozbité

Poctivý audit to musí říct jasně: nic z toho neukazuje, jestli je něco rozbité. Ukazuje to jen, jestli tam někdo je.

Některé z těchto projektů jsou jednoduše hotové. SetSimilaritySearch implementuje algoritmy pro podobnost množin; ty nerezaví. simhash je paper z roku 2007. Algoritmus pro extrakci obsahu v boilerpipe funguje v roce 2026 stejně jako v roce 2015 — bez ohledu na to, jak si vede proti moderním stránkám, kód se vám pod rukama neposouvá.

Co stárne, jsou věci s pohyblivým cílem na druhé straně:

• Automatizace v prohlížeči — každé vydání Chromu ji může rozbít.
• Chování HTTP klientů, které napodobují reálné prohlížeče — prohlížeče se mění a zamrzlá knihovna přestane odpovídat; sem patří tls-client.
• Parsery specifické pro konkrétní weby a pravidla extrakce pro jednotlivé weby — každá změna designu je chyba.
• Cokoli kolem třetí stranou poskytovaného API — vendor změní schéma a vy se to dozvíte až v produkci.
• Cokoli obalující LLM — změny modelů přicházejí rychleji než cokoli z toho.

Takže „1 606 dní zastaralé“ je pro jednu kategorii požár na pět poplachů, ale pro hashovací utilitu je to téměř irelevantní. Tady se žádné rozbití netestovalo a žádné tvrzení o něm nepadá; seřadit vlastní závislosti podle toho, do které kategorie spadají, nestojí nic a pomůže vám víc než samotné číslo zastaralosti.

Čtyři kontroly, které opravdu odpovídají na otázku

Žádná z nich není hlavička repozitáře.

Kontroly 1, 2 a 3 používejte jako rychlou triáž. Pak eskalujte, pokud metadata repozitáře chybí, přiřazení balíčku je nejednoznačné, aktivita se přesunula mimo výchozí větev nebo se registry artefakt rozchází s repozitářem. Neautentizovaná omezení GitHubu a zpoždění registrů znamenají, že slib „za jednu sekundu“ nedává smysl.

Když kontrola odhalí něco studeného v kategorii, která se rychle mění, udržované alternativy v této oblasti máme popsány v našich vlastních testech: Trafilatura pro extrakci obsahu, kterou dříve dělaly dragnet a boilerpipe, Scrapy nebo Crawlee pro crawlingové frameworky, Crawl4AI a Firecrawl pro LLM-orientovanou extrakci a Scrapling tam, kde záleží na odolnosti. Náš pillar o open-source scrapers sleduje širší přehled. Jde o recenze první strany; než uvěříte jakémukoli doporučení, včetně našeho, spusťte si sami všechny čtyři kontroly.

Limity těchto dat

• Výběr vzorku. Ručně vybráno kvůli podezření na opuštění. Z toho nelze číst míru celého ekosystému.
• Žádné testování funkčnosti. Ani jeden z těchto 35 nástrojů nebyl spuštěn proti živému webu. Zastaralost je signál údržby, ne verdikt o funkčnosti.
• Downloady zahrnují i stroje. CI, zrcadla, bez deduplikace a s okny bez společného konce. Objem instalací, ne lidi a ne rozhodnutí.
• Sedm neznámých příčin zůstává neznámých. Activity feed nic nevrátil a u pěti ze sedmi to nevysvětluje retence. Prázdná buňka je lepší než populární hádanka.
• staleness_days používá data committerů. Přepsaná nebo zpětně datovaná historie by ho zkreslila. Nic takového nebylo zjištěno, což není totéž jako to, že to neexistuje.
• Jeden referenční datum. 2026-07-27. Některé z těchto repozitářů se od té doby posunou — zejména newspaper, který commituje pravidelně. Spusťte kontroly znovu; necitujte moje data.

Kde managed služba mění situaci

Každá z těchto kontrol existuje proto, že u self-hosted knihovny nesete stárnutí vy sami. Když zamrzlý HTTP klient přestane fungovat jako aktuální prohlížeč, je to váš incident, v hodinu, kdy se objeví.

Poznámka autora: Thunderbit je náš managed produkt pro scraping. Managed služba přenáší část údržby na dodavatele, ale do rizikového modelu přidává pokrytí, dobu odezvy, vendor lock-in a kontinuitu poskytovatele. Thunderbit nebyl v tomto auditu repozitářů hodnocen.

Poctivý kompromis je jednoduchý: vzdáváte se možnosti číst zdrojový kód, připnout verzi a opravit si to ve dvě ráno sami. Pro tým, který už scrapery udržuje, je často správná volba open-source cesta — a právě čtyři kontroly jsou způsob, jak z toho udělat rozhodnutí, ne domněnku.

Vyzkoušet Thunderbit pro extrakci webových dat

Stručná verze

Sestavil jsem seznam, abych dokázal, že GitHub skrývá opuštěnost projektů. Iluze je reálná u 14 z 35 repozitářů a v jednom případě naprosto výrazná: sjdirect/abot ukazuje push z minulého týdne proti výchozí větvi zamrzlé od roku 2021, tedy rozdíl 1 802 dní.

Ale mechanismus je užší než celý příběh. Devět repozitářů splňuje všechny podmínky, které tvrzení vyžaduje, a jen dva z těchto devíti — splash a geziyor — mají pozitivní důkaz, že nafukování způsobili boti; zbytek splňuje hranici jen kvůli absenci důkazů. Dva označené repozitáře jsou případy, kdy se lidé snažili projekt oživit a neuspěli. Jeden, crawlab, má 12 250 hvězdiček a vývoj prostě přesunul na develop. U sedmi se activity feed vrátil prázdný a retence u pěti z nich nevysvětluje nic, takže příčina není prokázaná, jen předpokládaná. A u 21 z 35 repozitářů GitHub stálost zobrazil správně.

Nejhorší případ v datasetu projde všemi kontrolami na úrovni repozitáře. codelucas/newspaper byl commitnut 2026-07-21; newspaper3k, naposledy vydaný 2018-09-28, byl ten měsíc stažen 813 513krát. Ve vzorku 16 balíčků s releasy staršími než rok dohromady tvoří přibližně 2,28 milionu instalací měsíčně.

Jako základní triáž kontrolujte datum commitu na výchozí větvi, datum vydání v registru, příznak archived a v npm i pole deprecation. Než vyvodíte závěr, ověřte přiřazení balíčku k repozitáři a vývoj mimo výchozí větev.

Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free

FAQ

Co je pushed_at a proč neznamená „naposledy aktualizováno“?
pushed_at je pole GitHub API, které stojí za časovou značkou aktivity v hlavičce repozitáře, a obnoví se pokaždé, když se něco pushne do libovolné větve. Nejnovější commit na výchozí větvi je jen jeden signál údržby repozitáře, zatímco správci balíčků obvykle instalují artefakty z registru nebo vyřešené verze modulů. V tomto auditu mělo 14 z 35 repozitářů obě GitHub data od sebe vzdálená o více než 180 dní.

Je to vždy dependabot, kdo tu časovou značku nafukuje?
Ne, a právě to se ukázalo jako nejslabší část lidového příběhu. Pokud počítáme jen události, které nastaly po posledním commitu na výchozí větvi, jsou boti potvrzeni u 3 ze 14 označených repozitářů (splash 4 ze 4, geziyor 5 z 5, any23 16 z 16). U 2 je to vyloženě špatně: rozdíl u dragnet vznikl tím, že člověk pushnul nepropojený port na Python 3.10. Další dva jsou smíšené, včetně crawlab, kde 24 lidských pushů mířilo na develop a test, zatímco main stál. A u 7 activity feed nic nevrátil, takže příčina není prokázaná — retence vysvětluje jen dva z těchto sedmi případů.

Znamená zastaralý repo, že je nástroj rozbitý?
Podle těchto dat ne — nic z toho nebylo spuštěno proti živému webu. Zastaralost záleží na tom, jak rychle se cílové prostředí mění: automatizace v prohlížeči, HTTP klienti napodobující chování prohlížeče, parsery pro konkrétní weby a API/LLM obaly stárnou rychle, zatímco algoritmické knihovny jako SetSimilaritySearch nebo simhash mohou být i roky staré a přitom naprosto v pořádku. tls-client je ve vzorku nejsilnější případ: 790 305 instalací měsíčně z repozitáře, který je studený už 905 dní.

Jak může být repo aktivní, ale balíček mrtvý?
To je codelucas/newspaper a zároveň nejdůležitější zjištění celého auditu. Jeho výchozí větev byla commitnuta 2026-07-21, tedy pár dní před datem měření, ale newspaper3k na PyPI byl naposledy vydán jako 0.2.8 dne 2018-09-28 — tedy před 2 858 dny — a přesto má 813 513 stažení měsíčně. Kontroly na úrovni repozitáře projdou všechny; artefakt, který instalujete, je osm let starý. Vždy kontrolujte datum posledního vydání v registru odděleně od commit logu.

Řeší to archivované repozitáře? GitHub přece ukazuje banner.
Ne spolehlivě, a @modelcontextprotocol/server-puppeteer ukazuje proč. Jeho npm pole repository je null, takže z balíčku nevede odkaz na archivovaný repozitář a není co přeskočit. Co npm skutečně zobrazí, je řetězec deprecated balíčku — „Package no longer supported“ — vypsaný při instalaci, a 127 232 instalací měsíčně tím stále projde. browserbase/mcp-server-browserbase oznámil ukončení správně ve svém posledním commitu; jeho 20 389 instalací mu z velké části předcházelo, takže samy o sobě říkají jen málo.

Jak rychle zkontroluji vlastní závislosti?
Začněte datem commitu na výchozí větvi, datem verze/nahrání v registru, polem deprecation v npm a příznakem archived v repozitáři. Pak ověřte přiřazení balíčku k repozitáři, při odlišné aktivitě zkontrolujte nevýchozí větve a než začnete mluvit o transitivním dopadu, použijte dependency grafy nebo lockfile. Kolize názvů, jako jsou nesouvisející projekty wayback v Javě a na PyPI, dělají takový postup nezbytným.