# The Open-Source Traction Metric Reference for Deal Screening

*You will be able to take any repository number in a deck, state what it proves about adoption, and name the exact way it was inflated or misread.*

- Canonical URL: https://www.refolk.ai/guides/open-source-traction-metric-reference
- Pillar: Investing and deal sourcing
- Format: Reference
- Published: 2026-08-13
- Last reviewed: 2026-08-13
- Reading time: 14 min

You are screening an open-source or developer-tool startup and the deck is full of repository numbers: stars, forks, contributors, downloads. This reference tells you, metric by metric, what each one proves about adoption and commercial potential, and the specific way it gets inflated or misread. It is built for early-stage investors and platform partners who need to price a traction claim in minutes, not read five maintainer-facing blog posts to decode one chart.

The core move is simple and it runs against how most decks are built: sort every number into interest or usage, trust usage, and treat interest as an invitation to investigate. Do that and you can look up any cited metric below, read what it proves, and read exactly how it lies.

## Interest metrics vs usage metrics: the one distinction that does the work

Interest metrics show that someone noticed a project. Usage metrics show that someone depends on it. The load-bearing term is "vanity metrics" for the interest bucket, and the whole screen turns on keeping the two apart.

Stars and watchers sit in the interest bucket. A star merely shows that someone "liked" the project, as opposed to actively using or monitoring it. Package downloads, dependent projects, and active or unique monthly contributors sit in the usage bucket. The trap in most decks is that founders present interest metrics with the emotional weight of usage metrics, because interest numbers are larger, easier to grow, and easier to buy.

One caution before you lean too hard on the contributor side of the usage bucket. The most commonly accepted adoption metrics are heavily focused on contributors and community, on the logic that healthy contributors equal healthy adoption. But that shows only part of the picture: many projects have small contributor bases yet are widely adopted, and the inverse is also true. Contributors are a moat signal, not a headcount of users.

#### The traction claim, from noisiest to hardest to fake

1. **Stars / watchers** - Interest. Cheap to grow, cheap to buy, decays within two months.
2. **Downloads** - Usage, but unfiltered. Inflated by CI, mirrors, and publish bursts.
3. **Contributors** - Community health. Strong when sustained, weak as a user proxy.
4. **Dependent projects** - Hardest to fake. Proves something is actually built on the code.

*Read a deck's repository numbers from the bottom up, because the load-bearing signal lives at the base.*

> **Rule:** Do usage before interest
>
> When screening, evaluate downloads, dependents, and sustained contributors first, and treat stars as a lead to investigate rather than evidence. Maintainer-facing guides lead with contributors; for a screen, lead with what is hardest to fake.

## The metric reference: what each number proves and how it lies

This is the lookup. Each row names the metric, its bucket, what a clean number proves, and the counter-check that exposes the inflated version.

| Metric | Bucket | What a clean number proves | How it lies, and the counter-check |
|---|---|---|---|
| Stars | Interest | Someone found the repo notable enough to bookmark it | Bought or viral stars promote for under two months, then fade. Check stargazer account ages and spike months. |
| Watchers | Interest | A smaller set opted into notifications | Tracks stars closely; adds little beyond stars. Ignore unless it diverges from stars. |
| Forks | Usage-lean | People cloned the code to run or extend it | High stars with forks under 1% suggests gamed interest. Compute forks per 1,000 stars; aim for 10 to 20%. |
| Downloads | Usage | Machines or people pulled the package | CI runs, mirrors, and publish bursts inflate it. Confirm sustained above 50/day, tracking releases not user growth. |
| Dependent projects | Usage | Other codebases build on this one | Hardest to fake; absence is diagnostic. Pull GitHub "Used by"; zero dependents with big downloads is a red flag. |
| Contributors | Usage-lean | A community is developing the project | Can be dominated by one employer, and does not predict users. Count unique monthly contributors over 6 months. |
| Star AGR / growth rate | Interest | The star curve is steepening | Huge rates sit on tiny or new bases. Check absolute stars and whether the repo just crossed 1,000. |

The star growth rate deserves a note because founders love it. Runa Capital's ROSS Index ranks startups by the annualised growth rate of GitHub stars, restricted to repositories with 1,000 or more stars, using the maximum star growth over any 90-day period ending in the target quarter. It is a relative ranking, not a threshold. There is no published "good" AGR, so a founder quoting a growth rate without the absolute base is quoting a number you cannot bound. Ask for the base.

**925,978 - Projects in the study that found only a weak star-to-download relationship**

Stars and downloads measure different things, so citing both as traction double-counts one weak signal.

## Why stars are a decaying asset

Bought stars are a wasting asset, which is the single most useful thing to know when a deck leads with a star count. The promotion effect from a fake-star campaign lasts under two months before the stars become a liability rather than an asset.

The scale of the problem is now documented. A CMU, NCSU, and Socket study titled "Six Million Fake Stars" identified roughly six million suspected fake stars across 18,617 repositories and 301,000 accounts after processing. A related detector analyzed 20 terabytes of metadata and 326 million stars over a 2019 to 2024 window. Fake stars are not a fringe concern; they are a supply-chain-scale phenomenon, and they cluster in exactly the projects trying to raise on hype.

The tell is shape. A genuine star curve accumulates; a bought one spikes. Look for a vertical jump in a specific month, then inspect the stargazer accounts behind it for low activity and new creation dates. If the spike is 2024-onward and the accounts are thin, treat that month's stars as expired signal.

> A star spike in a deck is often already-expired signal, because the boost it bought faded before the round closed.

Here is why sustained contributors beat stars as a moat read. Bessemer, which explicitly calls stars vanity metrics, tracks unique monthly contributor activity instead. Fewer than 5% of the top 10,000 projects ever exceeded 250 monthly contributors, and only 2% sustained that across six months. Sustained engagement is rare and hard to fake, which is precisely what makes it a moat.

## The download trap: publish bursts, CI, and mirrors

A download count is a usage metric that behaves like a vanity metric unless you clean it, because the number counts machines, not people. npm does not filter automated downloads because bot filtering is hard, never totally accurate, and the registry is not an analytics company. The raw number is naive by design.

Three mechanisms inflate it. First, publish bursts: each version uploaded to the public registry typically receives 100 to 150 downloads from automated systems, mirrors, and scanners, so a startup shipping frequent releases mechanically inflates weekly downloads with no new users. Second, CI runs pull the package on every build. Third, most packages get a trickle that is not indicative of active use; only above roughly 50 downloads per day does the number become signal rather than noise. Download pumping is not theoretical: one package was inflated past 50,000 downloads in three days.

The counter-check has three parts. Strip the publish-day spike. Confirm sustained volume above 50 per day. Then cross-check against dependents, because downloads without dependents are the package-manager equivalent of stars without forks. A reported 70.46% of fake-star registry repos had zero dependent projects, which is why the dependent count is the most diagnostic single field you can pull.

#### Cleaning a download number before you trust it

1. **Strip publish spikes** - Remove the 100-150 automated pulls each version release triggers.
2. **Check the floor** - Confirm volume stays above 50 downloads per day, sustained.
3. **Match to cadence** - Verify the trend tracks user growth, not release frequency.
4. **Cross-check dependents** - Pull "Used by"; downloads with zero dependents are noise.

*A download count is not a usage signal until it survives all four filters.*

If pulling these signals by hand across a portfolio's worth of repos and their maintainers is the bottleneck, this is where a sourcing tool earns its place: you can go from a repo to the humans behind it, and from the humans to their prior employers, in one query instead of a dozen tabs.

I ran this search: `Top contributors to LangChain, MongoDB, and Grafana repositories who now work at early-stage companies.` - [see the full result list](https://www.refolk.ai/s/wx5ayz44nw).

*Returns named people with their current early-stage roles, so you can see where proven open-source maintainers are landing next.*

## Fork-to-star and dependents: the two fastest tells

Two ratios expose most gamed decks in under ten minutes, because both are hard to fake and easy to compute. Forks per 1,000 stars catches gamed interest; the dependent count catches empty downloads.

Forks measure people who cloned the code to run or extend it, which is closer to use than a star is. Practitioners cite a healthy band, and a repo far outside it is worth a hard look.

| Source | Healthy fork-to-star band | Warning sign |
|---|---|---|
| Peerlist analysis | 100 to 200 forks per 1,000 stars (10 to 20%) | Below that band |
| dev.to (A. West) | 10 to 30% | Under 1% |

A star count that looks healthy but sits on forks under 1% is the classic gamed pattern: interest was manufactured, but nobody cloned the code. Compute the ratio first thing.

Dependents are the other tell, and they are the hardest metric in the whole reference to fake, because faking them requires publishing real projects that import yours. Pull the GitHub "Used by" figure and the registry dependents. Big downloads with zero dependents means nothing is actually building on the package, which mirrors stars without forks and points the same way.

> **Watch out:** Absence is the signal
>
> Zero dependents alongside large download numbers is not a gap in the data. It is the data. It tells you the downloads are machines, not integrations, and it is one of the most reliable red flags in a screen.

## Discounting for funding and the thin commercial funnel

Two forces sit between real usage and real revenue, and both push you to discount: funding inflates the metrics, and the conversion funnel is thin even when usage is genuine. Skip either and you overprice.

Funding moves the numbers directly. Linux Foundation data on commercial open-source (COSS) companies shows what a round does to the curves.

| Metric | Average change after funding | As a multiple |
|---|---|---|
| Distinct contributors | +27% | 1.27x (derived) |
| Package downloads | 7x | 7x |
| Dependent projects | 8x | 8x |

A hockey stick right after a raise may reflect capital-driven distribution and marketing spend, not organic pull. Date every curve against the funding announcement and weight pre-raise organic growth far more heavily than the post-raise ramp. The same COSS work found that distinct contributors and the OpenSSF Criticality Score correlate with pre-money valuation, so these are the metrics the market is actually pricing.

Then discount for the funnel. Open-source SaaS free-to-paid conversion typically runs 0.5 to 3%, against 2 to 5% for traditional SaaS. Even genuine mass adoption converts to revenue at a fraction of the SaaS rate, so when you map usage to a revenue band, use the low end of that range unless the company shows a specific reason to beat it.

#### From cleaned usage to a revenue band

| Stage | Figure | Note |
| --- | --- | --- |
| Cleaned downloads / users | 100% | The number that survived the four download filters |
| Genuinely active users | variable | Users with dependents and sustained engagement |
| Free-to-paid conversion | 0.5-3% | Open-source rate, versus 2-5% for traditional SaaS |

*Genuine adoption narrows hard on the way to paid, so price the traction claim at the bottom of the funnel.*

## Screen a traction claim in seven steps

Run this in order. It takes a single analyst roughly 65 minutes plus 20 partner minutes to move a deck's repository claims from marketing to a defensible revenue band. Do usage before interest, because the hardest-to-fake signals should anchor the read.

#### The deck-to-verdict screen

1. **Pull the raw counts** - Record stars, forks, watchers, contributors, and last-commit date from the repo, plus registry downloads. End with a one-row, date-stamped snapshot per metric.
2. **Classify interest vs usage** - Tag stars and watchers as interest; tag downloads, dependents, and active contributors as usage. Every deck number should carry one label.
3. **Run fork and dependents checks** - Compute forks per 1,000 stars and pull the GitHub "Used by" count. Both the ratio and the dependent count go on the sheet.
4. **Test download quality** - Strip publish-day spikes, compare the weekly trend to release cadence, and confirm sustained volume above 50/day. Produce a signal-versus-noise verdict.
5. **Check contributor depth over time** - Count unique monthly contributors across the last six months and flag corporate concentration. Compare against the Bessemer 250 benchmark.
6. **Screen for fake-star signatures** - Inspect anomalous spike months and low-activity stargazer accounts. Flag or clear each spike month.
7. **Tie usage to the commercial funnel** - Map surviving usage metrics to a 0.5-3% free-to-paid conversion. Output a defensible revenue-potential band.

## How this screen goes wrong: seven false positives

Every metric in the reference has a failure mode, and each one is a specific way a real deck misleads a real screener. These are the patterns that survive a lazy read and get caught by the counter-check. Give this section the weight it deserves; the false positives are where money is lost.

- **Star spike misread as traction.** A vertical jump in stars from low-activity accounts, usually 2024-onward. Counter-check: inspect stargazer account ages and the spike months; fake boosts fade within two months, so the signal may already be dead.
- **Download count read as users.** Thousands of weekly downloads that are CI runs and mirror pulls. Counter-check: is it sustained above 50 per day, and does the trend track releases (publish bursts) rather than user growth?
- **Fork-to-star ratio gamed.** A healthy star count with forks under 1%. Counter-check: compute forks per 1,000 stars; genuine adoption sits near 10 to 20%.
- **Contributor count inflated by one employer.** A high contributor number dominated by a few corporate accounts. Counter-check: unique monthly contributors over six months, plus company-affiliation concentration.
- **Dependents absent.** Big downloads, zero dependent projects. Counter-check: pull GitHub "Used by" and registry dependents; downloads without dependents mirror stars without forks.
- **AGR without base.** A huge star growth rate on a tiny or young repo. Counter-check: check absolute stars and whether the repo just crossed the 1,000 threshold.
- **Contributor growth equated with users.** Rising PRs and issues framed as adoption. Counter-check: contributor metrics do not predict commercial success and can even move inversely to user counts.

#### Before you call the traction read done

- [ ] Every deck number is tagged interest or usage, and the read is anchored on usage.
- [ ] Forks per 1,000 stars is computed and sits inside or outside the 10-20% band.
- [ ] The dependent ("Used by") count is pulled; big downloads with zero dependents are flagged.
- [ ] Downloads are confirmed above 50/day sustained, with publish spikes stripped.
- [ ] Unique monthly contributors over six months is compared to the Bessemer 250 benchmark.
- [ ] Every spike month is inspected for low-activity stargazers and flagged or cleared.
- [ ] Post-funding curves are discounted against the 7x download and 8x dependent COSS averages.
- [ ] A revenue band is built on a 0.5-3% conversion, not a SaaS-rate assumption.

## Keeping the read current and staffing the team behind the metrics

Two things go stale fast in this work: the fake-star signatures and your feel for what a strong team behind the repo looks like. Both need a re-check cadence, not a one-time read.

Fake-star detection is an arms race. The scale numbers here (six million suspected fake stars, 326 million stars analyzed) come from a specific window, and the campaigns evolve. Rather than memorize a signature, re-run the mechanism each time: spike month, stargazer account age, activity, and the fork and dependent cross-checks. Those hold regardless of how the fakery is dressed up.

The team read is the other half of any open-source deal, because the metrics tell you about the code and the people tell you about the company. When you want to know whether a project's contributors are the kind of people who go on to build durable companies, or whether a founder can hire the developer-relations bench a COSS go-to-market needs, you are looking at the humans, not the repo. That is a sourcing problem, and it is where [Refolk](/) turns a metric into a shortlist.

```stat
number: 25,057
label: US developer advocate, DevRel, and community profiles in Refolk's index
note: Against 1,967 in the UK, a 12.7x depth gap that shapes where a COSS company can staff its community motion.

## Frequently asked questions

### Are GitHub stars a vanity metric for investors?

Largely, yes. A star records that someone liked or bookmarked a project, not that they use it. A study across 925,978 projects found only a weak relationship between stars and downloads, and fake-star campaigns can inflate the count for under two months before the boost fades. Treat stars as an interest signal that opens an investigation, never as proof of adoption, and always pair them with dependents and sustained contributors.

### What open-source metrics actually matter to VCs?

Usage metrics beat interest metrics: package downloads sustained above 50 per day, dependent projects (GitHub Used by), and unique monthly contributors held over six months. Bessemer tracks the last of these and found only 2% of top projects sustain 250-plus monthly contributors across six months. Dependents are hardest to fake, so their presence or absence is the most diagnostic single check when you are pricing traction.

### How do I tell real downloads from CI and bot noise?

npm does not filter automated downloads by design, so raw counts include mirror pulls and CI runs. Strip the publish-day spike (each version draws 100 to 150 automated pulls), confirm the volume stays above 50 per day, and check whether the trend tracks releases rather than user growth. Then cross-check against dependents: downloads with zero dependent projects mean nothing is building on the package.

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

Practitioners cite roughly 100 to 200 forks per 1,000 stars, or 10 to 20%, as a healthy band, with anything under about 1% as a warning sign. A high star count paired with almost no forks suggests the stars were bought or driven by a viral post rather than by people cloning the code to use or extend it. Compute forks per 1,000 stars as a fast tell.

### Should I discount traction numbers that appeared right after a funding round?

Yes. Linux Foundation COSS data shows projects average 7x downloads and 8x dependents after funding, alongside a 27% lift in contributors. A hockey stick immediately after a raise often reflects capital-driven distribution and marketing rather than organic pull, so date every curve against the announcement and weight pre-raise organic growth far more heavily.

### Do more contributors mean more users?

Not reliably. Contributor counts measure community health, not commercial adoption, and many widely used projects have small contributor bases while some high-contributor projects have few users. The two can even move inversely. Use sustained unique monthly contributors as a moat signal, but do not treat rising PR or issue activity as a proxy for the user base or for revenue potential.

---

*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/open-source-traction-metric-reference*