Sizing a Skill's Talent Pool From Its Open-Source Ecosystem

You have been asked how many people can actually do a specific technology, where they are, and whether you can trust the number. This guide is for strategy and research teams, talent-intelligence analysts, and operators sizing a market for a skill with no clean job title: a kernel subsystem, a GPU kernel framework, a protocol library. It delivers an end-to-end method that starts not from a resume title but from the open-source repository graph, and ends with a deduplicated, geolocated headcount you can defend in a leadership review.

The reason this exists: labor-market platforms do not index contribution history. When a skill is legible only in commits, reviews, and dependency edges, a title search overcounts by pulling in the whole host language and undercounts by missing the people whose profiles never say the word. The repository graph is the one place the skill is legible. This is the procedure for reading it.

Why title-based sizing fails for a niche skill

A resume title cannot see a niche skill, so it systematically overcounts by conflating the skill with its host language. Counting every Python developer as a PyTorch practitioner is the canonical error. The signal you actually want lives in who contributed to the specific ecosystem's repositories, not who writes the language it happens to use.

The size gap this produces is large and measurable. In Refolk's index of professional profiles, the United States CUDA pool is 16,289 people. The US Rust pool is 3,417. Both are a rounding error against SlashData's estimate of just over 47 million developers globally, up about 50% from just over 31 million in early 2022. The mechanism is concentration: an ecosystem-specific skill pools inside a handful of employers - NVIDIA tops CUDA in Refolk's index - so a title-based sizing that starts from the language pulls in orders of magnitude too many names.

The fix is to invert the starting point. Instead of filtering a labor-market index down by keyword, you build the pool up from the artifacts the practitioners left behind. That means traversing the technology's repository ecosystem, counting the humans who genuinely touched it, and only then attaching geography, employer, and a reconciliation against the broader market.

What the repository graph can and cannot tell you

The repository graph tells you who did the work; it does not reliably tell you where they live or who pays them. Treat the first as your spine and the second two as sparse overlays you report with coverage percentages, never as ground truth.

Three documented edges let you expand from a seed repository into its ecosystem. GitHub's dependency graph shows, for each repository, its dependencies (the ecosystems and packages it depends on) and its dependents (the repositories and packages that depend on it). Topic tags and forks are the other two edges. One hard limit: GitHub does not compute dependents on Enterprise Server, only on github.com, so dependents-based traversal breaks on self-hosted instances.

Location is the weakest layer. In a seven-year GitHub Archive study, slightly over 15 million accounts had public activity, and after fetching profiles about 2.3 million had a location listed - roughly 15%. That figure is self-reported and stale. Roughly six in seven contributors are geographically invisible to you, which means every geolocated headcount you produce is a lower bound.

Employer is inferred, not stated. The documented method reads commit-email domains and applies manual affiliation-mapping files such as cncf/gitdm. It is good enough to name the anchor employers in a niche - it will correctly surface NVIDIA for CUDA - but it will not resolve a personal-email committer to their day job.

The method, end to end

Run the nine stages in order; each has an owner, a rough duration, and a definition of done. Total effort is roughly six to nine working days for one technology, most of it in traversal, event extraction, and identity resolution.

Where the judgment lives

Two stages carry most of the risk. Traversal decides what counts as the ecosystem, and identity resolution decides who counts as a person. Get either wrong and the headcount is off by an order of magnitude in a direction you cannot see. The rest of this guide is mostly about defending those two stages.

Separating genuine practitioners from drive-by contributors

A genuine practitioner is defined relatively, by share of contribution, not by an absolute commit count. There is no published universal cutoff; the standard is the core-versus-periphery split, and it produces a surprisingly small core.

The dominant published method is the truck factor, which CHAOSS formalizes as the Contributor Absence Factor: the smallest number of contributors responsible for 50% of total contributions. The most-cited automated version, Avelino et al., assigns file authorship via a degree-of-authorship metric and iterates over the authors' file list, stopping when the current authors' coverage drops below half. Avelino fixes 3.293 as the minimal absolute DOA and 0.75 as the normalized threshold, at which 64% of selected authors are the top git-blame developer and 91% are among the top three.

The consequence for sizing is that the core is tiny by construction. Across 133 popular projects, 65% had a truck factor of two or fewer. A defensible genuine-practitioner count for any single flagship repository is often single digits. The headcount has to come from aggregating across the whole traversed ecosystem, which is exactly why traversal breadth matters more than depth on any one repo.

Do not discard the periphery. It is not the pool of genuine practitioners, but it is where you find people learning the skill, and for reconciliation you want both tiers labeled and counted separately. Report core and peripheral as two lines, and let the reader choose which definition of "can do this" their decision needs.

Deduplicating people without collapsing them into one

Identity resolution merges name and email aliases into persons, and at ecosystem scale its dominant failure mode is over-merge, not missed merges. This is the single most dangerous stage because its errors are invisible in the final number.

The scale of aliasing is real. Fry et al., analyzing World of Code, processed about 38 million author IDs and found roughly 14.8 million to have an alias, belonging to 5.4 million developers, with a median of two aliases per developer. Their resolution hit precision 0.99 and recall 0.84 against a 44-developer ground truth. A later World of Code map recorded 5.87 billion commits under 106.8 million distinct author strings, resolved down to roughly 62.7 million identities. So merging is not optional; a raw actor count double-counts most people.

But at that scale the failure direction flips. A handful of bridge identities - a shared placeholder email, a bot that commits under many names - can weld unrelated clusters into mega-components that absorb millions of people. A single careless transitive merge silently deflates your count by fusing distinct practitioners into one. The defense is to cap cluster sizes, blocklist role and placeholder emails, and inspect your largest resolved clusters by hand before trusting the total.

Bots are a related contaminant and a separate step. Strip [bot]-suffixed actors trivially first, then run a classifier on the rest. Named tools include BIMAN, BoDeGHa, and RABBIT/BIMBAS, the last built on a ground-truth dataset of 1,035 bots and 1,115 humans. Remove bots before you merge, or an automation account becomes the seed of a mega-cluster.

At ecosystem scale the risk inverts: the question is no longer who you missed, but who you fused.

Once the traversal and dedup are sound, the remaining work is a filtered search over the ecosystem you defined. This is where a general-purpose people index earns its place: rather than rebuild geocoding and employer inference from commit emails, you can express the pool directly as a query and get resolved, geolocated people back. Refolk is built for exactly this shape of ask.

Choosing the activity window and reporting two numbers

There is no canonical cutoff for "active," so report the count at two windows rather than pretending one is correct. The choice materially changes the headcount, and a five-year window quietly fills your pool with people who have left the field.

The documented options span a wide range. A common legal and tooling definition treats an active contributor as anyone who has made at least one change within the last 90 calendar days. CNCF's contributor program uses 18 months. CHAOSS's Augmented Pony Factor simply excludes inactive contributors without fixing a universal window. Return behavior complicates the binary: developers have between a 35% and 55% chance of returning to a project after abandoning it, so a lapsed contributor is not reliably gone.

The practical rule: publish the pool at a tight window and a loose one, and let the decision owner pick. A tight 90-day count answers "who is warm now"; a 12-month count answers "who genuinely works in this." Presenting a single window invites the reviewer to ask which one, and you will not have an answer that satisfies them.

The two tables you actually ship

Two comparisons make a niche pool legible: one skill across two geographies, and two skills within one market. Both come straight from Refolk's index and carry a derived ratio so the reader sees the shape, not just the raw counts.

Table A - One skill, two countries. CUDA talent is heavily concentrated in the United States, and the geography of the German pool is lumpier than general developer geography, clustering around Aachen and Munich rather than spreading nationally.

The US pool is 7.03 times the German pool. Because niche skills form around a handful of anchor labs and firms, you can build a defensible market map for Germany from three or four metros, not a national survey.

Table B - Two skills, one market. Holding the market constant shows how much the ecosystem, not the country, drives the number.

The US CUDA pool is 4.77 times the US Rust pool. Same country, same method, radically different size, driven entirely by which ecosystem you traversed.

Reconciling against labor-market data

Reconcile your OSS-derived headcount against a top-down population figure, and state the relationship as an assumption, because no source publishes an OSS-contributor-to-labor-pool ratio for a single niche skill. That unpublished two-layer gap - public contributors versus total practitioners - is precisely the judgment the analyst is being paid to make.

Use the top-down figures as anchors, not as additive layers. SlashData estimates just over 47 million developers globally; JetBrains estimates about 19.6 million professional developers. World of Code resolves 5.4 million developers from 38 million aliased IDs. Each row is a different definition of "developer," so you cannot add them.

The reconciliation move is to mirror SlashData's own method rather than trust any single layer. They analyze developer activity from GitHub, Stack Overflow, and employment statistics, plus their own survey, and calibrate external data against survey findings. You do the same at skill level: your OSS count is the floor of visible practitioners, the labor-market anchor is the ceiling of the addressable market, and the ratio between them is your stated assumption. Write it as "the OSS-visible core is X% of the estimated market, assuming Y," and the number survives a leadership review because its limits are on the page.

How this goes wrong

Eight failure modes account for nearly every wrong number in ecosystem-based sizing. Most inflate the count; a couple silently deflate it. Each has a cheap check.

Two of these deserve extra weight because they are invisible in the output. Over-merge deflates a number that still looks plausible, and VCS-only blindness drops real people: for a third of projects, some key engineers contributed not by writing code but by code-related activities not captured in the repository. Both are silent, so both need a deliberate check rather than a glance at the total.

Before you call the number done

Run this checklist before you present. It is ordered to catch the silent, count-changing errors first.

Keeping the number current

An ecosystem headcount decays as fast as the underlying activity, so treat it as a living figure with a re-check cadence, not a one-time deliverable. The active-window count moves every quarter as contributors lapse and return - remember the 35% to 55% return probability, which means your lapsed tier is partly a pipeline, not a loss.

Re-run the pull and dedup on a fixed schedule and diff the person set against the prior run. New core contributors joining an ecosystem is itself a market signal worth reporting: it tells a strategy team the skill is spreading or concentrating. When you re-check, hold the traversal rule and the activity windows constant so the delta reflects the market, not a change in your method. And when a decision hinges on geography, requery the geolocated overlay rather than trusting a cached location string, since profile locations are the fastest-decaying field in the whole stack.