The Developer Champion List From Public Build Signals

This is the procedure a developer-relations lead runs to turn "grow the community" into a ranked, evidence-backed shortlist of external developers to invite into a beta or advocacy program. It is written for devrel leads, technical founders, and technical sourcers who have no product telemetry, or who want to target developers building on a competitor's SDK where telemetry is impossible by definition. Everything here is sourced from public signals: package registries, the GitHub code graph, and public profiles.

The output is a list you can defend row by row. Each name carries a specific public signal, a numeric score, and a lawful basis for contact. You can run it start to finish in about two working days, and re-run it every quarter.

What public signals actually prove active use

Four classes of signal exist, and each proves something different. Package-registry dependents prove a project declared your library in a manifest. Code-search import matches prove an actual import or require line exists in source. Issue and discussion authorship proves a human is actively engaging. Follower and star counts prove public reach. Confuse these and your list fills with false positives.

The gap between "declared" and "used" is the one that sinks most champion lists. A manifest entry survives long after the code that used it is gone, and historical dependents linger in the graph. The ecosyste.ms API exposes a flag to include only packages whose latest version depends on yours, defaulting to on; you can set it off to see historical dependents, but for a champion list you want it on. GitHub's own dependency graph is worse: one accuracy study found roughly 20% errors in dependencies and around 10 errors in dependents. A raw dependent count overcounts.

Code search is the stronger proof because it inspects source, not metadata. The catch is that it is capped and best-match sorted, so you cannot enumerate exhaustively from it alone. The workable pattern is to seed with dependents and confirm with code search.

Which enumeration path to choose and its limits

Use the ecosyste.ms API to pull dependents across registries, and GitHub code search to confirm usage. Do not scrape GitHub's dependents page. That choice is forced by three hard facts about what the platforms expose.

First, GitHub does not provide the dependents or "Used by" count through its official REST or GraphQL API. The API tells you what a repo depends on, not which repos depend on it. The only way to read the count directly is to scrape the network dependents webpage, which can break or violate GitHub's terms. That missing API quietly pushes teams into exactly the behaviour the anti-spam scraping clause targets.

Second, the dependents tab only appears once more than 100 repositories depend on your package. Below that threshold, there is nothing to enumerate on GitHub at all.

Third, code search is rate-limited hard. The code-search category allows 10 requests per minute, and the Search API returns up to 1,000 results per query. General REST search endpoints run at 30 requests per minute, and the authenticated core REST limit is 5,000 requests per hour per OAuth app.

The cross-registry route around all of this is the ecosyste.ms open API, which covers npm, PyPI, crates.io, Go and more at a default 5,000 requests per hour based on your IP. Its open data is licensed CC-BY-SA, and it indexes 14.4 million packages across 109 sources. Routing dependents through it sidesteps both the rate ceiling and the legal exposure.

The rate-limit math dictates your batch design, not your ambition. At 10 code-search requests per minute against a 1,000-result ceiling, enumerating a popular SDK's users is a multi-hour, paginated job. Segment queries by language and filename up front rather than retrying blindly.

The counts above are illustrative. No authoritative funnel from raw dependents to champion shortlist for a mid-sized SDK is publicly established, so treat any such shape as arithmetic to sanity-check your own pull, not a target to hit.

Deduplicating one developer across repos and platforms

Key every person on their numeric GitHub user ID, never on a display name. The stable identity is the numeric ID plus login, both embedded in GitHub's noreply commit email format <id>+<login>@users.noreply.github.com. That number is the one thing a person cannot casually change.

Commit metadata is the bridge between a repo and a human, because every commit carries an author email you can fetch from a public repo. But two problems make this unreliable if you trust it naively. Names are configured locally, so a single login pushes commits carrying author names that do not identify the person behind the login. And identity attribution is spoofable: GitHub looks up the commit email against current users but lacks commit-level identity authentication, so a malicious user can attribute work to someone who never wrote it.

So the dedup rule is narrow: merge rows only when the numeric GitHub ID matches. For any collision on name or email, add a confidence flag and hold the merge for review rather than guessing.

There is a structural trap waiting here. The private-email setting is the GitHub default, so most commit emails resolve to the noreply form, and commit-email enrichment tools skip that form as a documented limit. Worse, the developers who keep private email on are disproportionately the active maintainers and security-conscious engineers you most want as champions. Your highest-value rows are the ones most likely to have no scraped contact channel. Plan for in-platform outreach from the start.

Scoring: what separates a champion from a casual user

Score every resolved person on four measurable dimensions, each derivable from public API fields, and attach the evidence to the row. No authoritative devrel-specific scoring rubric is publicly established, so treat this as a working rubric you calibrate to your own community, not a standard handed down from anywhere.

• Usage recency. The latest-version dependent flag plus the last commit date. Proves the integration is live, not archaeology.
• Depth of integration. A code-search import match plus the number of files touched. A library woven through many files beats a single manifest line.
• Public reach. Follower count, repo stars, and whether the person publishes talks or posts. Proves they can move others, not just themselves.
• Sentiment and engagement. Authored issues, discussions, and PRs on your project. Proves active investment in the tool.

Because the name and email noise described above is real, every score needs a confidence layer alongside it. A high score built on a spoofable or ambiguous identity is a liability, not an asset. Record the confidence flag next to the number so a reviewer can see which rows are safe to act on.

Recency:    0 = no commit in 12mo   ...   10 = active this month, latest-version dependent
Depth:      0 = manifest only       ...   10 = import confirmed across many files
Reach:      0 = <50 followers       ...   10 = publishes + speaks, high followers/stars
Sentiment:  0 = no engagement       ...   10 = authored issues/PRs/discussions on your repo
Confidence: LOW = noreply email + name collision | HIGH = numeric ID resolved, activity cross-checked
Evidence:   <paste the exact repo URL, import line, or issue link>
Total:      sum of four dimensions, gated by Confidence

When the resolve-and-score work is the friction, describe the shape of the person you want in plain language and let the search do the enumeration.

Refolk collapses steps two through five into a single query when you can name the language, recency window, and ranking signal, which is most of the time.

The procedure, start to finish

Run these nine steps in order. The whole thing is roughly two working days for one library, plus a one-off legal gate you reuse forever.

Ordering note: some practitioners lead with code search because it is stronger proof, using dependents only to seed. Either order works as long as both run and the shortlist requires an import match.

How this goes wrong

The failure modes below are where a defensible-looking list turns out to be noise, and where a lawful-looking send turns out to be a fine. Give this section the most attention, because it is the part that survives contact with an audit.

• Manifest-only dependents that were never imported. A repo lists your package in a lock file it never uses, or the dependent is stale. This is the single most common false positive. Require a code-search import match and set the latest-version flag; expect roughly 10% dependents error even then.
• Scraping the dependents page for counts. It can break or violate GitHub's terms. Use ecosyste.ms; if you must scrape anything, check it against the anti-spam clause first.
• Wrong-person attribution from commit metadata. A commit author name that does not identify the person behind the login. Key on the numeric GitHub ID and add a confidence layer; never trust a display name.
• Impersonated commits. A spoofed user.email attributes work to someone who never wrote it. Prefer signed commits and cross-reference profile activity before scoring.
• Empty enrichment on your best targets. Active maintainers hide their email by default, so your highest-value rows have no email. Default to in-platform outreach rather than treating email as the primary channel.
• Treating "public" as "contactable." Public data is not consented data; scraping a public profile does not exempt you from GDPR or CCPA. Run the Legitimate Interest Assessment and the role-relevance test before contact.
• One-region compliance assumption. A send that is CAN-SPAM-legal in the US can breach German rules. Segment by country and treat Germany as needing high-relevance, personalised messages.
• Slow opt-out handling. Even a lawful send fails audit if suppression lags. Suppress before the next send to that contact, not merely within the 30-day window.

The legal gate: what outreach the rules permit

GDPR applies even to public data, so the gate is a compliance step, not a formality. Public data is not consented data: once you store and use a scraped profile, it is personal information under GDPR and CCPA regardless of where you found it. The workable basis for B2B outreach is legitimate interest under Article 6(1)(f), which permits cold email provided the message is relevant to the recipient's professional role, you disclose where you obtained their data, and you include a clear opt-out.

Jurisdiction is the binding constraint, not consent. The same evidence-led message can be lawful under UK legitimate-interest guidance yet risky in Germany, where the stricter view expects at least a loose prior business relationship or a contact sourced from a public professional context. US CAN-SPAM does not require prior consent at all but still imposes sender-identification and opt-out requirements. So the same list needs different handling by country. The downside of getting this wrong is not abstract: GDPR fines reach up to €20 million or 4% of global annual revenue, whichever is higher.

Jurisdiction, not consent, is the binding constraint on outreach, so segment by country before you write a word.

Note the research-scraping carve-out does not help here. Researchers may scrape public, non-personal information from GitHub only if resulting publications are open access. A champion program is commercial, so it does not qualify; rely on legitimate interest for the outreach and on ecosyste.ms for the data pull.

Hi [name],

I saw you imported [library] in [repo] and have been active on it for [timeframe].
I found you through public GitHub and package-registry data.

I run the [product] developer program and I'm inviting a small group of people
already building with it into an early beta. Given your work on [repo], I'd love
to have you in it.

If you'd rather not hear from me, reply "stop" and I'll remove you before I send anything else.

Verify before you call the job done

Run this checklist against the finished list before a single message goes out. Every item is a specific check, not a topic to think about.

Keeping the list current

A champion list decays. New developers adopt your SDK, existing ones churn to a competitor, and today's casual user becomes next quarter's top contributor. Re-run the full pull every quarter, and treat the previous run as a diff rather than a fresh start: new import-confirmed repos are your incremental outreach batch, and rows that lost their latest-version flag or went quiet drop down the ranking.

Two things change underneath you between runs. Rate limits and API surfaces shift, so re-confirm the code-search cap and the ecosyste.ms limit each quarter rather than assuming the numbers here still hold. And the compliance posture in any given country can tighten, so revisit the Legitimate Interest Assessment annually and whenever you enter a new market. The supply picture explains why the effort is worth it: with only 323 US and 46 UK DevRel professionals in Refolk's index against thousands of developers per skill community, a ranked public-signal shortlist is how a small team keeps covering a community it will never fully staff against.