You can source engineers without paying for anything. It takes longer, it does not scale past a handful of roles, and it is genuinely effective — plenty of good hires come from an afternoon of GitHub search and a well-written email.
This guide covers the syntax that works, the free tools worth knowing, and where free stops being the cheaper option.
GitHub search: the core syntax
GitHub's search covers users directly. The operators that matter:
language:rust location:portugal followers:>50
That is the basic shape. Useful modifiers:
| Operator | Example | What it does |
|---|---|---|
language: | language:go | Developers whose repositories are primarily in that language |
location: | location:berlin | Matches the free-text location field |
followers: | followers:>100 | Follower count above a threshold |
repos: | repos:>20 | Public repository count |
created: | created:<2018-01-01 | Account age, a rough proxy for experience |
type:user | type:user | Excludes organisations from results |
Combined into something realistic:
language:typescript location:spain repos:>15 created:<2020-01-01 type:user
Two things to know before you rely on this. location: is free text, so "Berlin", "Berlin, Germany" and "🇩🇪 Berlin" are three different searches and you need to run all of them. And GitHub caps user search results at 1,000, so a broad query silently truncates. Narrow with created: ranges and run several passes rather than one wide query.
Google X-ray search
X-ray searching means using Google to search a site more flexibly than the site's own search allows.
site:github.com "rust" "berlin" -inurl:repositories
For personal sites and portfolios, which surface engineers who never appear in recruiting tools:
site:*.dev "senior engineer" "golang" -site:jobs.*
For conference speakers, a consistently underused pool:
"speaker" "kubernetes" 2025 conference -site:linkedin.com
The advantage over GitHub's own search is that Google indexes README files, personal sites and bios, so you can search for context that GitHub's structured filters do not expose.
Free sources beyond GitHub
Stack Overflow. The developer story feature is gone, but user profiles still show tags, reputation and location. High reputation in a narrow tag is a strong specialist signal.
Conference talk archives. Speaker lists from the last few years of any conference in your stack are a curated list of people who both know the subject and can explain it. Almost nobody sources from them.
Open-source contributor lists. Pick a library your team depends on and read its contributor graph. These people already understand your problem domain.
Community Slack and Discord groups. Language and framework communities usually have one. Participating for a few weeks before posting anything is the price of entry, and it is worth it.
Our public skill pages. Aggregate developer counts by skill and by country are free to browse without an account. Useful for sizing a market before you commit to a search strategy.
Finding contact details
Having a shortlist is not having an inbox. In order of reliability:
- The GitHub profile itself. Many developers list an email or personal site directly.
- Commit metadata.
git logon any repository they have contributed to exposes the author email on every commit — public information, and usually the address they actually read. - Personal site. Check
/aboutand/contact. - Their other profiles. Many link Twitter, Mastodon or a blog from their GitHub bio.
Commit emails are public, but people rarely expect to be contacted at them. Use the address, keep the message short and relevant, and never add it to a bulk sequence. This is the fastest way to get a reputation as someone worth ignoring.
Writing an email that gets a reply
Free sourcing succeeds or fails here. The pool is the same one paid tools search; the difference is entirely your message.
Reference something specific. Name the repository. Say what you noticed. Anything that could have been sent to a thousand people will be treated as if it was.
Keep it under 150 words. Every additional paragraph reduces the reply rate.
State the money. Engineers overwhelmingly report discarding messages without a range. Omitting it does not preserve negotiating room, it just costs you replies.
Give an easy no. "Not looking, but happy to point you at someone" converts far better than a hard ask, and referrals from uninterested engineers are one of the best channels there is.
A workable template:
Subject: Your work on [repo]
Hi [name] — I came across [repo] while looking at [specific thing].
[One sentence on what you actually noticed.]
We're building [one line] at [company], and looking for someone
to own [area]. It's [salary range], [location or remote policy].
Worth a conversation? Equally happy to hear it's a no, or to be
pointed at someone you rate.
[Your name]
Where free stops being cheaper
Free sourcing costs time instead of money, and past a certain volume the trade goes the wrong way.
The 1,000-result cap means broad searches truncate silently. You cannot tell whether you saw the market or a fifth of it.
No dedupe. The same person appears under different identities across sources and you will contact them twice.
No activity filtering. GitHub search cannot express "contributed in the last six months", which is the single most useful filter in sourcing.
Location is unreliable. Free text means "SF", "San Francisco" and "Bay Area" all need separate searches, and many people leave it blank entirely.
Manual contact lookup runs a few minutes per candidate. At fifty candidates that is most of a working day.
The rough breakpoint: free works well for one or two roles at a time. Past three concurrent roles, or a second hiring round in the same market, the hours spent exceed what a self-serve tool costs.
A realistic workflow
- Size the market first on the free skill and country pages so you know whether you are searching a pool of 500 or 50,000.
- Run four or five GitHub searches with different location spellings and
created:ranges. - Save every plausible profile to a spreadsheet with the repository that caught your attention.
- Spend two minutes per profile reading their most substantial repository. Cut aggressively.
- Find contact details for the survivors.
- Write individually to each. Twenty personal emails beat two hundred generic ones.
- Follow up once after a week. Once, not three times.
Expect a reply rate somewhere between 15% and 40% if the messages are genuinely specific — considerably better than most automated sequencing achieves, because almost nobody does this properly.
When manual searching stops scaling, our index covers the same public data with the activity filters GitHub search cannot express, and you can start on a free account.