Placing a Technology Category on Its Adoption Curve

This guide is for strategy and research teams, talent-intelligence analysts, and operators deciding whether an emerging technology category is a durable trend worth building a market or roadmap around, or hype that will fade. It turns the diffuse open-source footprint of a whole category into a single weighted score, then maps that score to a named adoption state you can defend in a strategy review. You come out with a number, a phase, and a rationale a colleague can challenge.

Most open-source reads score one repository's traction or list signals in isolation. This one aggregates the signals across the 5 to 15 repos that make up a category and returns a go/no-go, because a strategist commits research and headcount to a category, not to a repo.

What this framework decides, and why a category not a repo

The decision is binary in the end: is this category real and durable enough to fund, or is it a spike that will fade? The output is a weighted 0 to 100 score for the whole category and one of four adoption states.

A single repo can be gamed, abandoned, or an outlier. A category is the honest unit of analysis because a real technology movement shows up as a rising tide across several projects at once. When you score AI-agent frameworks or vector databases as a set, one bought spike or one single-vendor project cannot carry the verdict.

The four states this framework assigns:

The state names sit on top of Gartner's five-phase Hype Cycle: Innovation Trigger, Peak of Inflated Expectations, Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity. Early-but-real maps near the Innovation Trigger, accelerating spans the rise into the Peak, hype-peaked is the Peak itself, and fading is the slide into the Trough. The Hype Cycle is a perception-based model, and one of its stated limitations is the absence of empirical metrics. The mapping of each phase to a specific open-source pattern is my own synthesis, not a published standard, so treat it as a lens rather than a law.

The dimensions and what each one proves

Five dimensions carry the score. Each one proves something specific, and each one has a way it lies.

• Star growth against percentile benchmarks. Proves relative momentum. It lies when the stars are bought or when a niche repo is judged against a band it does not belong to.
• Metric coherence (forks, issues, downloads moving with stars). Proves that popularity is real, not purchased. It lies rarely, which is why it is the anchor.
• Contributor breadth and depth. Proves a community exists beyond the founders. It lies when bots inflate the author count.
• Vendor concentration. Proves whether the movement is broad or one company. It lies when automated commits masquerade as human breadth.
• Talent footprint. Proves how far the category sits from a mature plateau. It lies least of all, because a professional hiring base is slow and expensive to fake.

The single most consistent rule across every source I reviewed is that real adoption lifts multiple metrics together while a spike lifts stars alone.

The growth benchmarks that make a score comparable

Raw star counts mean nothing without a reference distribution. Runa Capital's published benchmarks give hard percentiles you can score against, and they turn "this looks big" into "this sits in the top quartile."

The best-project zone is the intersection of the upper quartiles by stars, above 3,700, and by star growth, above 25%. Forks track stars almost exactly, so a fork line that has decoupled from the star line is itself a contamination signal rather than independent evidence.

Two caveats keep this honest. First, these benchmarks apply only to repos with 1,000 or more stars. The ROSS Index, which ranks the fastest-growing projects by annualised star growth rate, uses the same 1,000-star floor. Do not judge a 500-star niche project against the 3.7K band. Second, star growth accelerates with size: the median growth rate rises with the number of stars, so a category's largest repos can look "accelerating" purely from scale. Anchor the state call on breadth, not on the headline growth of the biggest project.

De-contamination: the step that comes before scoring

De-contamination is the removal of fake stars and bot-inflated contributor counts before any dimension is scored. It runs first because contamination is now a base-rate problem, not an edge case.

The scale is documented. A CMU, NCSU, and Socket study using the StarScout tool analysed 20 terabytes of GitHub metadata, 6.7 billion events and 326 million stars from 2019 to 2024, and identified roughly 6 million suspected fake stars across 18,617 repositories by about 301,000 accounts. AI and LLM repos were the largest non-malicious fake-star category, with around 177,000 fake stars. If roughly one in six qualifying repos is touched by a campaign, skipping this step lets contamination distort the whole category aggregate.

There is a feedback loop that makes this worse for exactly the categories you most want to evaluate. Startups active on GitHub are 15 percentage points more likely to have raised a financing round. Capital chases stars, stars get gamed, and category-level star aggregates inherit that bias. This is the strongest reason to weight dependents and package downloads above raw stars, because downloads are harder to fake than GitHub stars.

The three checks that catch most contamination:

1. Plot star growth over time. A vertical cliff followed by a plateau is a purchase signature; organic growth is a curve.
2. Inspect stargazer profiles. Dozens of accounts created in the same week, or empty accounts with no other activity, are a coordinated campaign.
3. Cross-check forks, issues, and downloads. Flat forks and a flat issue tab against a star jump is the tell.

Persistence is the cleanest filter of all. Fake stars have a promotion effect only in the short term, under two months, and become a burden after that. A category whose star growth survives a two-month window is far more likely early-but-real than hype-peaked.

Measuring concentration without being fooled by bots

Concentration answers whether a category is a broad movement or one company's project wearing a movement's clothes. CHAOSS gives the named metrics for this.

The Contributor Absence Factor, formerly the Bus Factor, is the smallest number of contributors responsible for 50% of total contributions; a lower value means higher dependency on fewer people. The Elephant Factor is the minimum number of companies whose employees contribute a set percentage of commits, so a value of 1 means one company provides the majority and a value of 3 means three are needed to reach it. CHAOSS deliberately declines to fix a universal threshold: a small organisation may accept a bus factor of 2, while a larger one expects much higher before calling a project viable.

Compute the Elephant Factor across the category's repo set, not per repo. A category where every leading project resolves to the same handful of employers is a single vendor's push, not a durable trend, no matter how the star totals read.

This is the failure that quietly breaks the framework. Concentration metrics silently degrade under automation, so compute Elephant, Absence, and Pony factors on human-authored contributions only. If you cannot separate humans from agents, treat the concentration score as unknown rather than as a pass.

The talent-market cross-check

The professional footprint of a category is a leading state indicator, and it is the hardest signal in this framework to fake. Open-source stars can be bought overnight; a hiring base takes years to build.

In Refolk's index of professional profiles, 276 US professionals list a LangChain skill against 138,018 listing Kubernetes. That makes the mature cloud-native talent base roughly 500 times the emerging AI-agent base in the US. Read that way, an early-but-real category can post explosive open-source star growth while its professional base is still about one five-hundredth of a plateau category. The footprint gap is itself an adoption-state signal.

To compute the cross-check, pick a mature reference category in the same broad domain, pull its professional count and your target category's count from the same index in one pass, and divide. A ratio near 1 says the category is already mature; a ratio in the hundreds says it is genuinely early, however loud the GitHub signals are. Pulling both counts from a single source in one query keeps the comparison clean, which is where Refolk removes the friction of stitching together public profile data by hand.

The scoring procedure

Run these eight steps in order. Two orderings exist in practice: security-first sources put de-contamination and health scoring before popularity, while growth-investor sources lead with star-growth percentiles and curate afterward. I put de-contamination third and before scoring, because a contaminated input poisons every downstream dimension.

The weights in step five are a framework choice, not a published standard. A defensible default is to give metric coherence and talent footprint the highest weight, contributor breadth and vendor concentration the middle, and raw star growth the lowest, because star growth is the most gameable input. Write the weights down so a reviewer can argue with them.

Star growth vs Runa percentile ...... weight 0.15
  90+  top quartile (>26%/yr, 3.7K+ stars)
  60   above median (>13%/yr)
  30   below median
  0    niche repo below 1K stars (not scorable)
Metric coherence (forks/issues/downloads) ... weight 0.30
  90+  all metrics rising together
  40   stars rising, others flat
  0    stars-only spike, forks decoupled
Contributor breadth (human authors) . weight 0.20
  90+  broad outside contribution
  40   founders plus a few
  0    one or two authors
Vendor concentration (Elephant Factor) ... weight 0.20
  90+  Elephant Factor 3+
  50   Elephant Factor 2
  0    Elephant Factor 1 (single vendor)
Talent footprint ratio ............... weight 0.15
  90+  within 10x of a mature reference
  50   10x to 100x
  20   over 100x (very early)

How this read goes wrong

Every dimension has a false positive. This is the section to reread before you present, because a wrong go/no-go costs a quarter of misdirected research. Each row below is a way the aggregate deceives you and the check that catches it.

The lead-time trap deserves its own attention. Peer-reviewed work links release behaviour to future dependent growth, with minor releases showing consistent adoption benefits across JavaScript, Python, and Ruby at one and two years post-release, but no single clean figure ties dependent-count growth to a percentage of one-year adoption, so present a range rather than a point estimate.

The batch-signature check is worth naming twice because it is the fastest tell. Dozens of stargazers whose accounts were all created in the same week is a coordinated campaign, and because 90.42% of flagged repositories had been deleted as of January 2025, a repo that vanishes between two of your pulls is its own signal.

Verify before you present

Run this checklist before the score leaves your desk. Each item is a thing to confirm, not a topic to consider.

Keeping the read current

An adoption-state call is a snapshot, and the ground moves. Re-run the score on a fixed cadence rather than treating one verdict as permanent, because the whole point of the two-month persistence filter is that time separates real trends from spikes.

Three things go stale fastest. Contamination rates change: the 16.66% base rate is a mid-2024 figure, so re-run StarScout-style checks each cycle rather than trusting a stale exclusion list. Benchmarks drift as ecosystems grow, since star growth accelerates with size and the percentile bands shift upward over time. And the talent footprint moves slowly but decisively; a category whose professional base closes the gap toward a mature reference is migrating from early-but-real toward the plateau, and that migration is the clearest evidence a bet is paying off. Refolk's index gives you the moving footprint number on demand, so the talent cross-check can be refreshed as cheaply as the GitHub pull.

Set a quarterly re-score for categories you are actively funding and a semi-annual one for watchlist categories. When a state changes, write down which dimension moved it, because the reason is what a strategy review will ask for next.