Calling a Category's Default From Competing Open-Source Repos

You have been handed a field of competing open-source projects and asked one question: which one is becoming the category standard? This guide is for strategy, research, and talent-intelligence teams who must answer that from public repository and package data alone, with a verdict they can defend. It runs one real category race end to end - the AI agent frameworks - with the actual signals, the thresholds, and the two forks where the star leader turned out to be the adoption laggard.

The trap is that the loudest number is the least trustworthy one. Stars are cheap to buy, easy to spike, and they decay. The signals that name a winner - downloads, dependents, fork ratio, contributor breadth - cost more intent and are harder to fake. This teardown carries all of them side by side so you can watch the ranking change as you move from hype signals to adoption signals.

What "becoming the default" actually means in repo data

The default in a category is the project the most other people build on, not the one with the most stars. It shows up as high package downloads, a large and approximate dependents count, a fork-to-star ratio in the organic band, and contributor density that holds up over time.

Every one of those is measurable from public data. None of them is the headline number on the repo page. That gap is the entire job: a launch spike and a category default look identical on the star count and completely different everywhere else.

Hold two ideas together. First, benchmark quality does not decide the winner. In the AgentPulse study, benchmark score and adoption were nearly uncorrelated, at rho=0.05, which means an agent's task-completion capability does not predict how widely it is adopted. Second, breadth beats headcount: one project can become the substrate the others build on top of. In the agent-framework corpus, LangChain attracted 82.5% of cross-ecosystem contributors - the developers who commit to more than one competing framework. That is what a default looks like from the inside.

The default is the project the most people build on, not the one the most people applauded.

The field and the frozen snapshot

Start by naming the rivals and fixing a date. Every metric here moves, so a comparison is only honest if all rows come from the same day.

For this teardown the field is the agent frameworks studied across 15 projects: LangChain, AutoGPT, MetaGPT, and LangFlow carry through as the worked example, with LlamaIndex as the named challenger. The study corpus behind these numbers is large enough to trust: 15 frameworks, 808,042 stars, 73,997 pull requests, 86,241 commits, and 987,330 user profiles.

Record two things per project before you pull anything: the owner/repo slug and the package name in each registry where it ships. LangChain, for instance, is one slug on GitHub and a separate package name on PyPI. If you skip the package name here you will stall at the downloads step later.

Fork-to-star ratio: the cheap first cut

The fork-to-star ratio is your first screen because forking costs more deliberate intent than starring, and that intent is much harder to buy. Divide forks by stars; organic projects land in a known band, and anything well below it earns a closer look.

Published analyses citing the StarScout work put organic projects at a fork-to-star ratio of 0.10 to 0.24, with manipulated repos often falling below 0.05. A parallel report gives a tighter healthy band of 0.10 to 0.20 and flags a real example at 0.052. Because fork-per-1000-stars is the ratio times 1,000, the organic band is roughly 100 to 240 forks per 1,000 stars and the suspect zone is below about 50.

What the ratio proves: real people cared enough to copy the code, not just applaud it. What it looks like when it lies runs in both directions. A deep infrastructure library gets installed rather than forked, so it can post a low ratio and still be organic - check downloads before you cry manipulation. A tutorial or course repo gets forked heavily by learners with near-zero production use, so a high ratio there is not adoption at all. In one independent 20-repo check, manipulated projects showed 36% to 76% of their stars from zero-follower accounts and a fork-to-star ratio below one-tenth of the organic baseline. The number that is not for sale exposes the one that is.

Anomalous stars: when the spike is bought

If a repo tops the field on stars but sits in the suspect fork band, run the anomaly check before you trust any of its numbers. The reproducible method scores starring events on three signals and flags any event that trips two or more.

The three public signals are account age distribution, star velocity patterns, and stargazer activity levels. Bot accounts cluster under 60 days old, real spikes leave a velocity burst, and purchased accounts show near-zero activity elsewhere. The two-or-more rule matters because a single signal in isolation can describe a legitimate user - a new developer with an incomplete profile who starred a repo shortly after creating an account trips the age signal alone and is not a bot.

The scale of the problem justifies the check. StarScout covered 6.7 billion events and 326 million stars from 2019 to 2024, flagging roughly 6 million suspicious stars across about 18,600 repositories and 301,000 accounts. By July 2024, 16.66% of all repositories with 50 or more stars were involved in fake star campaigns, up from near-zero before 2022. The detection held up against reality: 90.42% of flagged repositories and 57.07% of flagged accounts had been deleted by January 2025.

There is a practical wrinkle. Since July 2026, GitHub has restricted the stargazer listing endpoints to admins and collaborators, so sampling stars on a repo you do not own may be blocked. When that happens, fall back to GH Archive or BigQuery for the history. A missing anomaly score is a gap in your evidence, not a clean bill of health - note it as unknown rather than assuming the stars are clean.

Production-adoption signals: downloads and dependents

These are the signals that actually name a default, because they measure someone building on the project rather than noticing it. Two are worth pulling: package downloads and the GitHub dependents count.

Package downloads come from the registry APIs - the PyPI stats JSON, the npm registry API, and crates.io. Read the 30-day trend, not the lifetime total. The registry excludes known mirrors, but CI re-installs still inflate the count, and a rising 30-day curve is far more honest than a large cumulative number. Two limits bind you: the stats JSON keeps only 180 days of history, and it rate-limits aggressively, returning a 429 after a couple of rapid calls. Pull once, cache, and reach for BigQuery when you need a longer velocity curve.

Dependents are the "Used by" count on the repo page, closer to "someone built on this" than any star ever gets. The GitHub API does not expose this number, so tools parse the HTML page instead. Treat the figure as a floor: GitHub's own docs say the dependent counts are approximate and may not match the listed dependents, and the number misses private and enterprise repos entirely. A project that looks like a loser on dependents may carry hidden production use, so read it beside downloads rather than alone.

Contributor signals: the mark of a durable winner

Contributor metrics separate a launch from a category default, because a default keeps attracting people who write code long after the launch buzz fades. Three metrics do the work, all computed from pull request and commit authors.

The first is contributor density: contributors per 1,000 stars. This is where the agent-framework race breaks open.

The second is cross-ecosystem breadth - the share of developers who contribute to more than one competing framework. LangChain functions as shared infrastructure, attracting 82.5% of cross-ecosystem contributors. The third is retention: contribution retention drops most steeply in the first 30 days after a first contribution and stabilizes near 90 days, so a project keeping contributors past 90 days is holding a real community.

One caveat on the definition. The contributor metric here is restricted to pull request and commit authors, which captures code contribution but excludes issue authors, reviewers, and other non-code contributors. It undercounts community in a consistent way across all repos, so it stays fair for ranking even though it is not a full census.

The procedure, end to end

Here is the whole teardown as a repeatable sequence. Each step names what you pull, roughly how long it takes, and what done looks like.

On the API mechanics: GET /repos/{owner}/{repo} returns stargazers_count and forks_count; GET /repos/{owner}/{repo}/contributors gives the authors; per_page maxes at 100 and you paginate with page. For the weekly star series, pages of the stargazers stats endpoint move backward toward the repository's creation week, and concatenating them produces one continuous series where weeks without stars read zero.

| Repo | Stars | Fork ratio | %anomalous | Downloads 30d | Dependents | Density /1k |
|------|-------|-----------|-----------|---------------|------------|-------------|
| repo-a |  |  |  |  |  |  |
| repo-b |  |  |  |  |  |  |
| repo-c |  |  |  |  |  |  |
Verdict: ______ wins on ______; star leader ______ ranked ___ on adoption.

The two wrong turns in this race

Both wrong turns come from letting the star ranking lead. Watching them happen is the point of the teardown, because your own field will offer the same temptation.

The first wrong turn is crowning AutoGPT. It gained 111,967 stars in one month, more than enough to top most fields on the headline number. But it converted fewer than 9 contributors per 1,000 stars against LangChain's 41 - roughly a 4.5x density gap the star ranking hides completely. Stars priced a launch moment; density priced the community that stayed. Ranking on stars would have named the adoption laggard as the category default.

The second wrong turn is trusting benchmark quality. It is natural to assume the technically strongest project wins, but benchmark score and adoption are nearly uncorrelated at rho=0.05. A framework can top the leaderboard and lose the category, which is exactly why downloads and dependents have to sit beside any capability claim. The teardown's verdict lands on LangChain not because it scored best on a benchmark, but because it leads on downloads, dependents, contributor density, and the 82.5% cross-ecosystem breadth that marks a substrate.

Refolk's index echoes the same verdict from the human side. Among professionals in the United States, 18,812 list LangChain as a skill against 1,056 for LlamaIndex, a 17.8x breadth lead. The skill counts lag real adoption because people update their headlines slowly, so treat them as a breadth proxy rather than live demand - but a gap that wide corroborates the repo signals rather than contradicting them.

When you need to read where a category's default is landing across regions and seniority, pulling the skill breadth directly is faster than reconstructing it from repos. Refolk returns those professional segments from plain-English queries, so a claim like the 17.8x gap above is one search rather than a scraping project.

How this goes wrong

Most bad verdicts come from trusting one signal past its limit. Each signal proves something narrow and lies in a specific way, so the defense is always corroboration across signals rather than precision on any one.

• Fork-ratio false negative on infra libraries. Deep dependencies get installed, not forked, so a low ratio can be entirely organic. Check downloads and dependents before calling manipulation.
• Fork-ratio false positive from tutorials. Course and tutorial repos get forked heavily by learners with near-zero production use, so a high ratio is not adoption. Cross-check dependents.
• Single-signal star flag over-triggers. A real new developer with an empty profile trips the account-age signal alone; only two or more signals should flag a starring event as anomalous.
• Dependents undercount. The number is approximate and misses private and enterprise repos, so a project that looks like a loser may carry hidden production use.
• Downloads inflated by CI and mirrors. The registry excludes known mirrors, but CI re-installs still inflate the count, so compare the 30-day trend rather than lifetime totals.
• Stale star series. The download stats JSON keeps only 180 days, so any long-run velocity curve needs BigQuery, not the JSON API.
• Skill-count lag. Professional skill counts trail real adoption because people update their headlines slowly; read them as a breadth proxy, not live demand.
• Access-restriction gap. Since July 2026, stargazer sampling may be blocked without admin rights, so a missing anomaly score is a gap in evidence, not a clean bill of health.

One more discipline worth stating plainly: fake stars are self-liquidating, which makes time the referee. The promotion effect lasts under two months and becomes a liability afterward, so a star curve that climbs, plateaus, then holds flat outranks a single sharp spike. If you can only glance at one thing on the star history, look at whether the shape survived past two months.

Before you call the verdict

Run this check before you send the answer. It exists to stop a clean-looking table from resting on one unverified signal.

Keeping the verdict current

A category default is a moving target, so treat the verdict as perishable. The mechanisms that make it move are known, which lets you set a re-check cadence instead of guessing.

Re-run the fork ratio and 30-day downloads quarterly; these move fast enough that a two-quarter-old table is stale. Re-pull contributor density and cross-ecosystem breadth less often, since community depth turns slowly and is the least gameable signal. Watch for two shifts specifically: a challenger crossing into the organic fork band after a suspect start, and a download trend that inverts the current ranking. Either one is your cue to run the full teardown again rather than patching one number.

The signals themselves also drift. The stargazer access restriction landed in July 2026, and registry rate limits and history windows change without notice, so re-confirm what each endpoint returns before you rebuild a table on it. The method is durable; the plumbing under it is not, and a standard that overclaims on stale plumbing is worse than one that says plainly where its evidence has gone thin.