How to find and source developers on GitHub

Five steps. The order is the point: each one narrows the pool cheaply so the expensive step runs on the fewest people.

1. Translate the role into query terms. One or two languages, a handful of ecosystem topics, a star floor. Not a wishlist — the two or three things that would actually disqualify someone.
2. Find repositories, not people. language:go topic:kubernetes stars:>=100 returns the projects where the work you are hiring for is being done.
3. Mine contributors. Pull the contributor list for each repository. This is where the candidate pool comes from, and it is the step most people skip.
4. Screen on evidence. Language depth in the relevant language, recency of activity, and whether their contributions are substantive rather than drive-by.
5. Resolve contact details last. It is the most expensive step per person, so it should run only on the shortlist. See how to find a developer’s email.

Because search/users only knows what people typed into their profile. Its useful qualifiers are essentially language, location, followers and repos — and languagethere means “the most common language across their public repos”, which is a weak proxy for expertise.

Three concrete failures:

• It rewards self-description. A senior distributed-systems engineer whose profile is blank is invisible; a bootcamp graduate with a keyword-stuffed bio is prominent.
• It mixes in organizations. Without type:user you get company accounts in your results.
• It cannot express the thing you care about.There is no qualifier for “has written production Go against the Kubernetes API”. But there is a repository query that finds projects doing exactly that, and those projects have contributor lists.

Use user search as a supplement — it is the only place location filtering exists — never as the primary discovery path.

Three qualifiers do almost all the work, and one of them is regularly set wrong:

The star floor is the common mistake. Setting stars:>=5000 feels like a quality filter and behaves like a pool-destroying one: you end up repeatedly sourcing the same well-known maintainers, who are the least likely people in the ecosystem to be available. A floor around 50–200 finds the serious mid-sized projects where most of the actual employable talent is.

Sort by stars descending for relevance, but page deeper than the first screen. The third page of results is where the non-obvious candidates are, precisely because everyone else stops at the first.

For each repository, pull its contributor list. That gives you handles attached to evidence — you know which project they worked on and roughly how much, before you have looked at a single profile.

Carry the source repository forward with each handle. It is worth doing for two reasons. First, it is context for outreach: “I saw your work on X” is a different email from “I found your profile”. Second, it makes contact resolution dramatically cheaper — you already know a repository this person has demonstrably committed to, which turns the highest-yield email lookup into a single targeted API call rather than a hunt.

Deduplicate as you go. The same people contribute across many repositories in one ecosystem, and that overlap is itself a signal: someone who appears in four projects in your target domain is more deeply embedded in it than someone who appears in one.

Then throw people away, aggressively. Drop:

• Bot accounts — anything ending [bot], plus the usual CI identities.
• Organization accounts, which appear in contributor lists.
• Single-commit contributors, unless the commit is substantial.
• Accounts with no activity in the last year or two.

The ratio is stark and worth internalising: on a real run, 3,963 discovered accounts became 130 worth screening, and 100 with a usable address. Sourcing is a funnel with a very wide mouth.

Ranked by how much they tell you per unit of effort:

• Depth in the specific language, not breadth.Substantial code in one language beats “knows twelve”. A profile listing twelve languages usually means tutorials in eleven of them.
• Recency. Someone who last pushed anything in 2021 has either moved to private repos at a job — plausible and fine — or moved on. Either way you cannot assess current skill from stale code.
• Contributing to projects they don’t own.This is the most under-rated signal on GitHub. Getting a change merged into someone else’s codebase means reading unfamiliar code, following a review process, and responding to feedback — which is most of the job.
• Domain overlap with your problem. Someone who has shipped against the API you use starts months ahead.
• Reviewed and discussed, not just committed. Thoughtful issue and PR comments are the closest public proxy for how someone works with colleagues.

• Total commit count and contribution graphs.Trivially inflatable, and heavily distorted by whether someone’s employer uses public repos.
• Follower count. A popularity proxy, not a skill one. Useful only as a coarse spam filter.
• Stars on their own repositories. Measures marketing reach and timing at least as much as engineering quality.
• An empty profile. Says almost nothing. Plenty of excellent engineers work entirely in private repositories; the absence of public work is not evidence of absent skill. This is the single most important asymmetry to hold onto: GitHub can tell you someone is good; it cannot tell you someone is not.

Because GitHub’s location is a free-text field the user typed, not structured data. “SF”, “San Francisco”, “Bay Area”, “California”, “Earth” and an empty string are all common, and the field is frequently years out of date.

So treat location: as a weak, optional narrowing — set it only when the role genuinely requires a location, and expect it to shrink your pool far more than it should. Filtering hard on location also introduces a real proxy-discrimination risk, which is worth being deliberate about rather than incidental (see below).

GitHub’s API budget, and it binds much sooner than people expect.

Two budgets, not one, and the search budget is the one that bites: 30 requests a minute is nothing when repository discovery and commit search both draw on it. Any stage that spends search quota belongs late in the pipeline and behind a gate.

Which is why ordering matters more than speed. Our contact-resolution cascade averages 2.0 calls per person by exiting at the first usable address; running every stage for everyone would cost about seven. That single design choice is the difference between roughly nine searches an hour on one token and barely three.

Four public sources, in yield-per-call order: the profile email field, the author email in public commit metadata, commits in their own recent repositories, and public GPG key user IDs. Used with an early exit, that reaches 93% of a contributor-mined pool.

Two things to know before you start. The technique most guides still recommend — reading commit emails out of GET /users/{login}/events/public — no longer works; GitHub removed the commits array from that payload. And 29% of the addresses in commit metadata are @users.noreply.github.com privacy artifacts that must be discarded, never decoded.

Both are covered in detail, with measured hit rates, in how to find a developer’s email address on GitHub.

GitHub is a strong signal of demonstrated work and a biased sample of engineers. Both are true, and pretending otherwise builds a worse pipeline:

• Public work correlates with free time. Open-source contribution skews toward people without caregiving responsibilities or second jobs. A GitHub-only pipeline systematically under-represents them.
• Whole industries work in private. Finance, defence, healthcare, most enterprise software. Their engineers have thin profiles and deep skills.
• Proxy filters are still discrimination.Location can proxy for national origin; account age and “years of activity” can proxy for age. Use them only where the role genuinely requires it, and record why.
• Never let a score be the decision. A ranking — ours included — is decision support for who to talk to. A human makes the hiring decision, and for the same reason you should not use sourcing signals as an employment background check.

The practical version: use GitHub to find people you would otherwise never have met, and never to rule outpeople who aren’t on it.

Automate the mechanical funnel: repository discovery, contributor mining, deduplication, bot and organization filtering, activity screening, and contact resolution. It is deterministic, it is where the API budget goes, and it is tedious in exactly the way software is good at.

Keep two things human. Judging fit— reading someone’s actual code and deciding whether this is a person you want on the team — and the outreach itself. A specific first line about the work someone actually did is the entire difference between a reply and a spam report, and it is the one part of this process that cannot be templated.