The Ecosystem Adoption Signal Reference for Technology Trend Reads

This reference is for the strategy analyst, talent-intelligence researcher, or operator who has to answer one question in a report: is this technology category actually growing, how fast, and who is winning. It gives you a row per open-source ecosystem signal - star velocity, download curve, dependent count, contributor influx, issue and fork rate, job-posting volume - with what each one proves and the specific way it inflates before you cite it. Read it top to bottom once, then keep it open and jump to the row you need when a strategy team pushes back.

Most public write-ups on this either sell a tool that overlays two charts or teach a maintainer to grow their own project. Neither helps you defend a market read. What follows is the lookup table an analyst uses to convert raw ecosystem activity into a trajectory statement that survives cross-examination.

What each ecosystem adoption signal proves, and what it does not

An ecosystem adoption signal is a public open-source metric you read to infer whether a technology category is gaining or losing ground. No signal measures real usage directly; each is a proxy that leaks in a known direction. The job is to know the direction of the leak before you cite the number.

Start with the shape of the whole system. Signals split into two families. Supply-side signals come from the code and its registry: downloads, stars, forks, dependents, contributors. Demand-side signals come from the labor market: job postings and the skills people list. The two families disagree often, and when they disagree the disagreement is the finding, not a problem to smooth over.

No platform publishes a numeric threshold that separates a real adoption signal from noise. npm states plainly that its counts are directional indicators of package popularity, not absolute numbers and not the number of users. The nearest thing to a documented composite is Libraries.io's SourceRank, whose maximum score sits at around 30 points. The academic guidance on stars is explicitly about shape, not level: gradual discovery reads differently from sudden synchronized bursts. So the correct posture is comparative and directional. You rank peers within a category and read curves, not levels.

Downloads: the strongest-looking signal, and the most machine-driven

Download counts prove that automated systems are pulling a package more often, which correlates loosely with adoption but is dominated by continuous integration. Per npm's own co-founder, most npm downloads are mostly CI machines, and a single download is simply a count of HTTP-200 responses that were tarball files. Read downloads as a relative, within-category signal and never as a user count.

The gaming case is settled. A developer documented pushing a package with almost no users past over one million downloads with no cost. On PyPI, mirrors using tools like bandersnatch sync by downloading all packages, recorded with bandersnatch as the user-agent, which inflates the counts of less common packages while masking real end-user downloads for common ones. PyPI's own disclaimer says this is difficult to quantify because mirrors do not report back.

There are two clean fixes. First, filter to real installs: on PyPI, filter on the details.installer.name column to count only downloads from pip. Second, watch the window. The npm registry API is capped at 18 months for all-time requests, so a package older than that looks artificially flat at its start unless you chunk the range endpoint. pypistats.org only serves the last 180 days; the full history lives in the PyPI BigQuery dataset populated through the Linehaul project, which streams complete logs.

1,000,000+

A second inflation trap sits at the library level. Summing sibling packages under one framework name can include addons and dependencies that also depend on the core package, which inflates the library-level number. When you report a framework total, name the constituent packages or you will double-count.

Stars and forks: attention signals that invert over time

Stars prove attention arrived, not that anyone shipped the tool. They lag real usage and, when manufactured, actively invert: fake stars generate a short-lived bump in genuine attention, but the effect is far weaker than real stars and turns negative over time. So a star total is one of the weakest levels you can cite and one of the most useful timelines you can read.

The scale of manipulation is why timeline shape beats level. A CMU study counted six million stars from July 2019 to December 2024 that appear to be fakes. Socket's StarScout work found 4,530,000 suspected inauthentic stars given by 1,320,000 accounts across 22,915 repositories. Manipulation is concentrated in time: at the July 2024 peak, more than 16 percent of GitHub repositories were associated with fake star campaigns. A level snapshot cannot see a burst; a monthly series can.

From raw stars to a star signal you can cite

1. Total stars on the repo

   100%

   the headline number, uncitable alone

2. After removing burst months

   variable

   synchronized lockstep stars stripped

3. Genuine star timeline

   variable

   read as shape, gradual vs sudden

The authenticity screen is mechanical. Look for lockstep: accounts with minimal activity, and account groups starring the same repositories within a short time. When a repo "takes off" in a single month, that is the signal to inspect, not to report. Forks carry a quieter version of the same problem: a fork count includes stale copies, vendored snapshots, and one-off experiments, so it proves distribution of the code, not active use of it. Pair fork counts with issue and pull-request rates from non-owner accounts before you read a fork total as engagement.

Dependents and SourceRank: the closest thing to a usage proxy

Dependent count proves that other real open-source projects build on a package, which is the sturdiest supply-side proxy for "this is working software." Libraries.io's SourceRank leans on it: if a lot of projects depend on it, that implies it is working software. SourceRank's stated design goal is a comparable number for packages within a given ecosystem, and Libraries.io monitors millions of libraries across 32 package managers.

The failure this creates is the one that ruins cross-category reads. A project in a smaller ecosystem gets a low score even if it is the most-used project within that whole ecosystem - the documented elm-versus-javascript problem. A dominant niche engine will score below a mass-market wrapper simply because the wrapper's ecosystem is larger. The fix is share-of-registry: normalize each project to the total volume of its own registry, and compare only within a category and abstraction layer.

This is where a demand-side pull earns its place next to the supply-side signals, because the two families disagree in ways a single chart hides. When you need the labor-market side of an adoption read fast, Refolk resolves a plain-English skill-and-place query into a counted set of professionals, so you can put a demand curve beside your download curve without stitching together three exports. I use it precisely at the moment a strategy team asks "but who is actually hiring for this," which no registry answers.

Job postings and skills: the demand side that overstates breadth

Job postings are widely framed as a leading indicator of technology demand, but raw post volume is lagging and often misleading because most recruiters reuse and repost the same listings. Bain's framing is the safe one: postings are a leading indicator of labor demand but do not measure employment levels. The genuinely leading signal is skills availability, which provides leading indicators of adoption rates, one major driver being the availability of skilled labor, particularly in the early stages of technology growth.

Two contamination patterns dominate. First, reposts: total mention volume often reflects past decisions, so prefer first-mention over repeat volume. Second, concentration: on Indeed, only about 1 in 20 companies had at least one posting mentioning AI, and almost 90 percent of all AI-related postings came from just 1 percent of companies. A booming aggregate can represent a handful of hyperscalers, not category-wide adoption. Volume can also mislead on direction: ML-engineer postings have fallen 47 percent since their early-2022 peak, yet openings are up 59 percent from 2020, so the baseline you pick decides the story.

A cleaner demand proxy is the count of professionals who list a skill, because it survives reposting. In Refolk's index of professional profiles, the US footprints of two systems languages tell a story a star chart would invert.

Two readings sit inside this table. Within one market, Go's US footprint is 4.68 times Rust's, so if your report leans on a stars-only read where Rust often trends, the demand side flatly contradicts it. Across markets, the same skill compresses: Rust shows 3,405 professionals in the US against 944 in Germany, a 3.6x gap. Reading a US-derived adoption curve as a global one overstates the category everywhere outside the US.

3.6x

When the star chart and the hiring count disagree, the disagreement is the finding, not an error to smooth away.