# Grading Whether a Repo's GitHub Traction Is Real

*Score any dev-tools repo across six authenticity dimensions and reach a defensible real, mixed, or inflated verdict before partner review.*

- Canonical URL: https://www.refolk.ai/guides/grading-github-traction-real
- Pillar: Investing and deal sourcing
- Format: Framework
- Published: 2026-08-04
- Last reviewed: 2026-08-04
- Reading time: 15 min
- Keywords: how to spot fake github stars, evaluate open source startup traction, github metrics that predict adoption, fork to star ratio benchmark, vc diligence dev tools github, is github traction real

## Key takeaways

- The raw star count is the cheapest signal to fake: at Redpoint's seed median of 2,850 stars, manufacturing that number costs $85 to $285, an ROI of 3,500x to 117,000x, so weight it near zero.
- Fork-to-star ratio splits clean from fake because bots optimize the visible counter, not the workflow: clean projects sit around 0.10 to 0.24 while manipulated repos fall below 0.05.
- 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.
- Open issues per star is the hardest signal to fake: clean repos over 100 stars run a median of 0.021, fake repos run 0.000, because manufactured stars never generate the friction of real use.
- Human adoption diverges from stars by an order of magnitude: in Refolk's index, 17,441 US professionals list LangChain as a skill against 804 for LlamaIndex, a 21.7x spread stars alone would compress.
- Deletion confirms but cannot originate a verdict: enforcement lags campaigns, so a still-live repo is not exonerated, which is why deletion status is the last check, not the first.

Before you take an open-source or dev-tools startup to partners, you have to decide one thing about its GitHub page: is the popularity real adoption, or manufactured signal. This guide is for early-stage investors, platform and talent partners, and angels who source on developer traction. It converts the StarScout fake-star research, fork-to-star benchmarks, and registry-adoption checks into a weighted dimension score with a real, mixed, or inflated cutoff you can apply to one repo on a Tuesday and defend in the room.

## Why the star count is the least trustworthy signal you have

The raw GitHub star count is adversarially optimized and carries the least evidentiary weight of anything in this framework. Founders know the benchmarks investors source on, and buying toward them is nearly free.

Jordan Segall, a partner at Redpoint Ventures, analyzed 80 developer-tool companies and found the median GitHub star count was 2,850 at seed stage, rising to 4,980 at Series A. Those numbers are useful context. They are also a published price list. Manufacturing a seed-credible count of 2,850 stars costs $85 to $285, against a seed round that unlocks $1 million to $10 million. The return on that spend runs from 3,500x to 117,000x.

**16.66% - Repositories with 50+ stars involved in fake star campaigns by July 2024**

StarScout found this up from near-zero before 2022, across 18,617 repos and roughly 301,000 accounts.

This is not a fringe problem. StarScout, the detection tool built at CMU, NC State, and Socket, analyzed 20 TB of data and 326 million stars from 2019 to 2024. It identified approximately 6 million suspected fake stars across 18,617 repositories by roughly 301,000 accounts. The share of popular repos touched by campaigns grew from near-zero before 2022 to one in six by mid-2024.

The practical consequence is simple. When you open a repo with 5,000 stars, you have learned that someone either earned or bought 5,000 stars, and you cannot tell which from the number. Everything real lives in the signals that require actual usage to produce.

> **Rule:** Weight the star count near zero
>
> Treat the raw star count as adversarially optimized. Score fork ratio, issue quality, and registry adoption instead, and let the star number contribute almost nothing to the verdict.

## The six dimensions that separate real from inflated

Score a repo on six dimensions, each of which requires genuine usage to produce and each of which fails differently when it lies. The star count is not one of them; it is the thing you are checking, not a signal you trust.

- **Fork-to-star ratio.** Real users fork because they intend to use or modify the code. Bots optimize the visible star counter and do not fork. This splits clean from fake more cleanly than any single number.
- **Stargazer profile quality.** Manufactured stars come from empty accounts. Zero-follower share and clustered creation dates expose them even when totals look plausible.
- **Registry adoption.** Public dependents and download trends are a downstream trail that paid star services do not simulate. Hard to fake, but blind to proprietary use.
- **Issue and PR quality.** Open issues per star measures the friction real usage generates. Manufactured stars generate none.
- **Contributor depth and retention.** Whether first-time contributors return for a second merged PR, and whether they are identifiable humans.
- **Enforcement status.** Whether the repo or its stargazers have been purged. A confirming signal only, because enforcement lags campaigns.

Here is how those signals look on real repos, organic and suspected, side by side.

| Repo | Stars | Fork-to-star | Zero-follower stargazers | Suspected fake |
| --- | --- | --- | --- | --- |
| Flask | 71K | 0.235 | ~10% | clean baseline |
| LangChain | 133K | 0.155 | 5.9% | clean baseline |
| AutoGPT | 183K | 0.090 | - | clean baseline |
| Union Labs | 74K | 0.052 | 52% | 47.4% |
| FreeDomain | 157K | 0.017 | 81.3% | flagged |

Read the table top to bottom. Flask and LangChain sit inside the organic band on fork ratio and carry single-digit zero-follower shares. Union Labs, at 74,000 stars, has a fork ratio of 0.052, right at the manipulation floor, and 52% of stargazers with no followers. FreeDomain is the archetype: 157,000 stars, only 168 watchers, 2,676 forks, and 81.3% zero-follower stargazers. Its watcher-to-star ratio runs 26x lower than Flask's.

#### The two-axis fake-star read

Horizontal axis runs from Low fork-to-star (<0.05) to Healthy fork-to-star (0.10-0.24). Vertical axis runs from Clean stargazer profiles to Ghost-heavy stargazers.

| Quadrant | What it means |
| --- | --- |
| Ambiguous, check registry | Cross-check downloads before calling inflated |
| Likely real, verify issues | The clearing zone, both axes agree |
| Inflated, near-dispositive | Flag: FreeDomain lives here |
| Laundered stars, sample deeper | Healthy ratio hides fake stars, sample harder |

*Fork ratio and stargazer quality together classify a repo that either signal alone would misjudge.*

The matrix is the reason you never clear a repo on one axis. A healthy fork ratio with ghost-heavy stargazers is the laundering pattern documented in the dossier, where a flagged project's ratio looked almost healthy while three-quarters of its stargazers had no followers.

## Why fork ratio works and where the band comes from

Fork-to-star ratio is the fastest reliable filter because forking requires intent to use, and paid star services do not simulate intent. Real users fork; bots do not.

Multiple independent analyses converge on the same shape. Organic projects average 0.10 to 0.24. A detection tool calibrated on labeled cases reports a clean median of 0.153 against a fake median of 0.055. Manipulated repos often fall below 0.05. The split is clean because the workflow bots skip is exactly the workflow the ratio measures.

Two cautions on the band. First, repo type shifts it. Framework, CLI, and library repos should carry higher fork ratios than tutorial or demo repos, because people fork things they build on. Second, the exact per-type thresholds are not publicly established, and sources disagree on the ceiling, with one range at 0.10 to 0.24 and a wider 0.09 to 0.235 seen across Flask, LangChain, and AutoGPT. Use the band as a filter, not a verdict.

> Forking requires intent to use, which paid star services do not simulate, which is why clean and fake split at 0.153 versus 0.055.

Watcher-to-star is a useful second axis for the same reason. Watching a repo is a deliberate act that bots skip. FreeDomain's 168 watchers against 157,000 stars is the signature of a counter that was inflated while every deliberate action stayed flat.

## Reading the stargazer list by hand

Sample stargazer profiles directly and score the share that are empty accounts, because manufactured stars come from accounts that were created to click and nothing else. This is the check that catches a repo the fork ratio missed.

Follow the published method: sample stargazer profiles across the repository by hand, without tooling, and look for the fingerprints. Score three things.

- **Zero-follower share.** In flagged projects, 36% to 76% of stars originated from zero-follower accounts. FreeDomain hit 81.3%.
- **Zero-repo share.** Accounts that have starred but never created or contributed to anything.
- **Clustered creation dates.** Synchronous, or lockstep, starring from accounts created in the same window is the core StarScout signal.

> **Watch out:** Aged accounts beat naive filters
>
> Premium campaigns use empty accounts over 1,000 days old to pass simple young-account filters. Check activity depth - real repos, real commits - not just account age.

The aged-account laundering problem is why account age alone fails. The empty shells that pass a young-account filter still have no followers, no repos, and no real commits. Score depth of activity, not the creation date.

If sampling profiles by hand across a repo and its peers is the friction, that is exactly where named-professional data helps. Rather than infer humans from empty stargazer accounts, you can check who actually lists the technology as a skill and contributes to it. That is a stars-independent axis, and it is where I come in.

I ran this search: `Engineers who list LangChain or LlamaIndex as a skill and contribute to open-source AI repos in the US` - [see the full result list](https://www.refolk.ai/s/y54be2z6px).

*Returns the named professionals whose real skill footprint sits behind a repo, a human-adoption read no star count can fake.*

## The human-adoption axis stars cannot fake

Named-professional adoption diverges from star counts by an order of magnitude, which makes it a signal you can weight heavily and one that no starring campaign touches. Real skills and real jobs are far harder to manufacture than a click.

| Comparison | Count A | Count B | Ratio |
| --- | --- | --- | --- |
| LangChain vs LlamaIndex skill (US) | 17,441 | 804 | 21.7x |
| Developer Advocate title, US vs Germany | 218 | 24 | 9.1x |

In Refolk's index of professional profiles, 17,441 US professionals list LangChain as a skill against 804 for LlamaIndex, a 21.7x spread. A star count would compress that gap; the human footprint keeps it open. When you want to know whether a repo has adoption a partner would believe, count the people who have staked a job or a listed skill on it.

The Developer Advocate row is a companion read with a caveat. A large DevRel footprint can reflect genuine community investment, or it can reflect marketing spend. Anchor it against dependents and downloads, never against stars, or you will mistake a hiring budget for adoption.

Two example searches make this concrete. To gauge real human adoption behind an AI dev-tool, look for engineers who list the technology as a skill and contribute to open-source repos in it. To surface the proprietary usage registry dependents miss, look for engineers at large enterprises who publicly depend on the package in their own repos. Both put named people, not counters, under the traction claim.

## Registry adoption: the downstream trail

Registry dependents and download trends measure whether anyone builds on the code, which is the one thing a star cannot represent. These are harder to fake than stars because they require real integration.

The dependents endpoint on Google's Open Source Insights exposes dependent counts for npm, Cargo, Maven, PyPI, and Go, derived from computed dependency graphs. Well-known packages such as react or gopkg.in/yaml.v3 carry tens of thousands of dependents. Treat the number as indicative of relative popularity, not a precise count, because only public dependents are graphed. The manual complement is the GitHub Used by badge and a search for the package in other repos' dependency files. Registry download numbers from npm and PyPI are a second, independent read.

#### The adoption trail a fake repo cannot produce

1. **Star** - A single click, free to buy in bulk
2. **Fork** - Intent to use or modify, bots skip this
3. **Public dependent** - Someone wired the package into their own build
4. **Download trend** - Sustained, version-diverse pulls from real installs

*Each stage requires more real intent than the last, which is why the trail thins out under a manufactured star count.*

Two blind spots keep registry data honest. A package used heavily inside proprietary applications shows few public dependents, so a low count is ambiguous and must be cross-checked against downloads before you call it inflated. And download counts include CI runs, bots, and mirror pulls. A flat, spikeless curve with no version diversity is the tell that the downloads are machines, not adopters.

## The scoring procedure

Run the eight steps in order, from cheapest to hardest evidence, then roll the dimensions into a weighted score. The whole pass takes about an hour for one repo and produces a verdict a partner can challenge on the specific dimension that drove it.

#### Grade a repo's traction in eight steps

1. **Pull the raw counts** - Use the GitHub API to grab stars, forks, watchers, open issues, and last push date. gh api repos/OWNER/REPO returns stargazers_count, forks_count, open_issues_count, and subscribers_count. Done: a one-row snapshot.
2. **Compute fork-to-star and watcher-to-star** - Divide forks by stars and watchers by stars. Place the fork ratio against the 0.10-0.24 organic band and the sub-0.05 floor. Done: two ratios read against benchmarks.
3. **Sample the stargazer list** - Sample stargazer profiles across the repo by hand and look for the fingerprints. Score zero-follower share, zero-repo share, and clustered creation dates. Done: a zero-follower percentage.
4. **Check downstream registry adoption** - Query the dependents endpoint plus npm or PyPI downloads and the GitHub Used by badge. Done: a public dependent count and a download trend read.
5. **Read issue and PR quality** - Compute open-issues-per-star and eyeball whether issues describe real usage friction. Compare against the ~0.021 clean median and the 0.000 fake median. Done: an issue-per-star ratio.
6. **Check contributor depth and retention** - Run git shortlog -sn and inspect whether first-time contributors return for a second merged PR by verified humans. Done: a contributor count and a retention read.
7. **Confirm with deletion and enforcement status** - Check whether stargazers or the repo were purged and cross-reference the StarScout dataset. Done: a confirming or disconfirming flag.
8. **Weight and assign a verdict** - Roll the dimensions into a weighted score with stars near zero. Map the total to real, mixed, or inflated. Done: a one-line verdict.

Sources disagree on ordering. Some practitioners run the fork-ratio and profile checks first as the fastest filter; others lead with registry adoption as the hardest-to-fake evidence. Both are defensible. Run the fast filter first when you are triaging many repos, and lead with registry adoption when a single repo is already close to partner review.

For the weighting itself, keep it explicit and copy it into every memo.

**Traction dimension scoring rubric**

```
DIMENSION                       WEIGHT   SCORE (0-2)   WEIGHTED
Issue quality (issues/star)       25       ____         ____
Fork-to-star ratio                20       ____         ____
Registry dependents + downloads   20       ____         ____
Stargazer profile quality         15       ____         ____
Contributor retention (2nd PR)    15       ____         ____
Named-professional adoption        5       ____         ____
Raw star count                     0       ____          0
-----------------------------------------------------------
TOTAL (max 40):  ____
Verdict cutoffs:  >= 30 REAL   |   18-29 MIXED   |   < 18 INFLATED
</template>

Open issues per star carries the most weight because it is the hardest signal to fake. For repos over 100 stars, the clean median is 0.021 and the fake median is 0.000. Manufactured stars never generate the friction of real usage, so a near-zero issue-per-star ratio on a high-star repo is close to dispositive.

## How this grading goes wrong

Every dimension has a failure mode, and most bad verdicts come from trusting one signal instead of the set. These are the specific ways a repo fools a careful analyst.

- **Healthy fork ratio, fake stars anyway.** A flagged AI project's fork-to-star ratio looked almost healthy, yet three-quarters of its stargazers had no followers and nearly a third were ghosts. Never clear a repo on fork ratio alone; always pair it with profile sampling.
- **Aged-account laundering.** Premium campaigns use accounts over 1,000 days old to beat young-account filters. Check activity depth, not just age.
- **Registry zero-signal is ambiguous.** Public dependents miss proprietary use, so a genuinely popular enterprise package can show few dependents. Cross-check downloads before calling it inflated.
- **Download counts inflated by CI and mirrors.** Registry numbers include bots and mirror pulls. A flat, spikeless curve with no version diversity is the tell.
- **Contributor spike that is bots.** An agent that opens PRs from freshly created accounts registers as a burst of new contributors, and the chart can spike in the same month the only maintainer stops reading notifications. Verify second-PR retention and human identity.
- **Deletion status as primary signal.** Enforcement is reactive and lagging, so absence of deletion proves nothing. A live campaign simply has not been purged yet.
- **DevRel headcount misread.** A large Developer Advocate footprint can reflect marketing spend, not organic adoption. Anchor it against dependents and downloads.
```

*Score each dimension 0-2, multiply by weight, sum. Adjust weights to your thesis but keep stars near zero.*

callout
kind: warning
title: The contributor chart lies in both directions
The New Contributors metric reports the same number for one engaged maintainer and one departed maintainer whose token still works. Bot-generated PRs from fresh accounts inflate it; a burst can coincide with abandonment. Only retention-to-second-PR by verified humans is load-bearing.
```

The deletion signal deserves its own discipline. As of January 2025, 90.42% of flagged repositories and 57.07% of flagged accounts had been deleted, against a baseline deletion rate of 5.03% for random repos versus 90.70% for lockstep-flagged ones. That confirms GitHub itself treated the flagged repos as illegitimate. But deletion happened only after public embarrassment, not proactive detection, and GitHub has never published its detection methods or enforcement statistics. So a purged stargazer list confirms a verdict you already reached; a still-intact one exonerates nothing.

## Before you take the verdict to partners

Run the checklist below before you write the traction paragraph in a memo. If any item is unchecked, your verdict is not yet defensible and a partner is entitled to send it back.

#### Traction verdict readiness

- [ ] Fork-to-star ratio computed and placed against the 0.10-0.24 band and sub-0.05 floor
- [ ] At least 30 stargazer profiles sampled by hand, with a zero-follower percentage recorded
- [ ] Account activity depth checked, not just creation age, to catch aged-account laundering
- [ ] Public dependent count pulled and cross-checked against a download trend
- [ ] Download curve inspected for version diversity, not just a flat total
- [ ] Open-issues-per-star computed and compared to the 0.021 clean median
- [ ] First-time contributor retention to a second merged PR verified as human
- [ ] Named-professional adoption checked as a stars-independent axis
- [ ] Deletion status used only to confirm, never to originate, the verdict
- [ ] Dimensions rolled into a weighted score with a written real/mixed/inflated cutoff

Keep the framework current by re-checking two things over time. First, the benchmarks move: because published VC benchmarks become the number founders buy toward, the seed and Series A medians are moving targets, so recompute the peer set rather than trusting a fixed star bar. To build that peer set, look at founders and CTOs of open-source infrastructure startups that raised a seed round in the last 12 months and compare their live signals, not their headline stars. Second, the detection tooling and the fakery evolve together; agent-generated PRs are a new contributor-chart failure mode, and the next one is not yet documented. Re-sample by hand when a repo's signals disagree, and let the dimension that is hardest to fake for that repo type carry the verdict.

## Frequently asked questions

### How many stars should a seed-stage dev-tools startup have?

Jordan Segall at Redpoint Ventures analyzed 80 developer-tool companies and found the median GitHub star count was 2,850 at seed and 4,980 at Series A. Treat these as context, not a bar to clear. Because manufacturing 2,850 stars costs $85 to $285, founders now buy toward that exact number, so a repo sitting near the median tells you almost nothing about real adoption. Weight the star count near zero and score the other dimensions.

### What is a healthy fork-to-star ratio?

Organic projects average roughly 0.10 to 0.24, and a detection tool calibrated on labeled cases reports a clean median of 0.153 against a fake median of 0.055. Manipulated repos often fall below 0.05. Framework, CLI, and library repos should carry higher ratios than tutorial or demo repos. Exact per-type thresholds are not publicly established, so use the band as a filter and always pair it with stargazer profile sampling.

### Can a repo have a healthy fork ratio and still be faked?

Yes. One flagged AI project showed a nearly healthy fork-to-star ratio, yet three-quarters of its stargazers had no followers and nearly a third were ghost accounts. Never clear a repo on fork ratio alone. Always sample the stargazer list for zero-follower share and clustered creation dates, and check downstream registry adoption before reaching a verdict.

### Which GitHub metric is hardest to fake?

Open issues per star and registry dependents are the hardest. Manufactured stars never generate real usage friction, so fake repos show an open-issues-per-star median of 0.000 against a clean median of 0.021. Registry dependents and download trends leave a downstream trail that paid star services do not simulate. A high-star repo with near-zero issues per star and no public dependents is close to dispositive of inflation.

### Does the absence of deletion mean a repo's stars are real?

No. GitHub enforcement is reactive and lagging: 90.42% of flagged repositories were deleted as of January 2025, but only after public embarrassment, not proactive detection. A still-live campaign has simply not been purged yet. Use deletion status only to confirm a verdict you already reached from live signals like fork ratio, issue quality, and stargazer sampling.

### How do I check adoption a package's own repo hides?

Registry dependents count only public dependents, so a package used heavily inside proprietary applications shows few. Cross-check download counts, and look for engineers at large enterprises who publicly depend on the package in their own repos. Named-professional adoption is a separate axis: in Refolk's index, professional skill footprint diverges from star counts by an order of magnitude, which surfaces real usage stars alone would compress.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/grading-github-traction-real*