When I started building outbound for a developer infrastructure company last year, I ran the standard playbook — Apollo filters, ZoomInfo exports, LinkedIn sequences. The response rate was 1.1%. Then I tried something that felt almost too obvious: I pulled the stargazers from three competing open-source repos, enriched the handles through People Data Labs, and sent 160 personalized emails. Reply rate: 13.4%. Booked meetings: 11.
The difference isn't outreach quality. It's that a GitHub star is a declared, timestamped signal of developer intent. LinkedIn "Open to Opportunities" tags are aspirational. GitHub stars are behavioral.
This playbook documents exactly how I built that workflow — from picking the right repo signals to landing enriched records in a CRM, without triggering GitHub's rate limits or burning through enrichment credits on profiles that'll never buy.
Why stars beat LinkedIn job titles for developer prospecting
LinkedIn lets you filter by job title, but "Senior Software Engineer" tells you nothing useful. It doesn't tell you whether someone evaluates infrastructure tooling, runs CI/CD pipelines, or has budget conversations. A GitHub star on a repo in your exact category does.
When I analyzed 500 stargazer profiles across three DevOps-adjacent open-source tools, 68% had profiles indicating they worked at companies with more than 50 employees, 41% had contributor history in related ecosystems, and 23% had forked the repo — which is a stronger intent signal than a star alone.
Fork behavior matters more than starring. Forkers are actively experimenting. Committers are already building. That's your qualification tier right there, before you've touched enrichment.
Picking repo targets: the signal tier list
Not every public repo produces qualified pipeline. The repos that work share a few characteristics.
High-signal repos: Tools in a category adjacent to yours that your ICP would evaluate. If you sell a monitoring platform, repos for Prometheus exporters, OpenTelemetry SDKs, or Grafana dashboards are your goldmine — not the star-count leaders like React or VS Code.
Avoid repos with more than 50k stars. The stargazer list is too broad — students, hobbyists, researchers — and signal-to-noise collapses fast. I tested this on a 90k-star repo: after enrichment, only 9% of resolved profiles mapped to companies with more than 10 employees.
Target range: 500–20k stars, active in the last 90 days (check the commit graph), in a specific technical category. Good starting points: your direct competitors' OSS tools, foundational libraries your product integrates with, and repos maintained by companies serving the same ICP.
Extracting stargazers and contributors without burning your rate limit
The GitHub REST API gives you everything — but the limits stop you fast if you're careless. Unauthenticated: 60 requests/hour. Authenticated with a personal access token: 5,000 requests/hour. At 30 stargazers per page, that's roughly 150,000 stargazer profiles per hour when authenticated — more than enough for most repos.
Three approaches depending on scale:
The GitHub API directly works fine for repos under ~5,000 stargazers if you're comfortable with Python or Node. The /repos/{owner}/{repo}/stargazers endpoint returns usernames and avatar URLs. Hit /users/{username} for each to get company, public email, blog URL, and Twitter handle. Basic, free, and gives you clean data to pipe into enrichment.
Apify's GitHub Star Gazer Actor is worth the $24/1,000 profiles when you want enrichment baked in. It scrapes personal websites linked in GitHub bios, extracts emails via regex, and pulls social handles. The enrichment is shallow — it surfaces whatever's publicly posted — but useful as a first pass before hitting a proper enrichment API. Real limitation: unauthenticated rate limits cap it at 60 requests/hour, so large repos will take time even with their built-in pausing logic.
Phantombuster's GitHub Stargazers Export is the cleanest option for non-technical teams. Set a repo URL, define your row limit, and it outputs a CSV with GitHub profile data. The phantom handles pagination and rate limiting automatically. Downside: it's raw GitHub data — you still need a separate enrichment step downstream.
For contributor extraction (higher intent than stars), use the GitHub API's /repos/{owner}/{repo}/contributors endpoint. It returns contributors sorted by commit count. The top 50 contributors to a category-relevant OSS repo are among the best-qualified leads you'll find — they've spent hours in a codebase that competes with or complements yours.
Enriching GitHub handles to real contact data
GitHub profiles give you a username, sometimes a company name, occasionally a public email. That's not enough to run outbound. You need work email, LinkedIn, job title, and seniority. Here's the enrichment stack I settled on after testing six combinations:
Step 1 — Company resolution: Most GitHub bios have a company field, often formatted as "@company" or a loose string like "Google / Stripe". Normalize these strings, then use the People Data Labs company enrichment endpoint to get normalized domain, headcount, and funding stage.
Step 2 — Person matching: PDL's person search API lets you query by (github_username, company_domain) or (full_name, company). Match rate in my tests: 54% for GitHub handles with company data, 31% without. When PDL misses, I fall back to Hunter.io's domain search to at least surface the common email pattern for that company.
Step 3 — Waterfall in Clay: For scale, I run the whole workflow as a Clay table. Import the GitHub username list, use Clay's built-in GitHub enrichment to pull bio fields, then waterfall through PDL → Hunter.io → Snov.io for email. Clay's waterfall consistently gets to 70–80% email coverage on this workflow in my experience.
Step 4 — Email validation: Before any send, run the list through NeverBounce or ZeroBounce. GitHub profiles go stale fast — people change jobs, abandon email addresses, move domains. I've seen 15% invalid rates on lists older than three months.
Extraction and enrichment tool comparison
| Approach | Cost | Setup | Email coverage | Best for |
|---|---|---|---|---|
| GitHub API (raw) | Free | Dev required | None — raw data only | Technical teams, any repo size |
| Apify Star Gazer Actor | $24/1K profiles | No-code | ~25% (public only) | Quick surface-level enrichment |
| Phantombuster Stargazer Export | ~$56/mo plan | No-code | None built in | Non-tech teams needing raw CSVs |
| Clay + PDL + Hunter.io waterfall | ~$0.10–0.30/row | No-code | 70–80% | Scale enrichment, non-technical teams |
| GitHub API + PDL direct | $0.01–0.05/match | Dev required | 40–55% | High-volume, cost-sensitive workflows |
The Clay waterfall is the most reliable path for non-technical teams. For anyone comfortable with an API who wants to control costs, the GitHub API + PDL combination is significantly cheaper at volume.
The full workflow: repo signal to enriched CRM record
Here's the exact sequence:
1. Identify 3–5 target repos using the criteria above (500–20k stars, active last 90 days, adjacent to your category). Prioritize competitors' OSS tools and heavily-starred libraries your product integrates with.
2. Pull stargazers and fork list via the GitHub API or Phantombuster. Separate into intent tiers: starred-only (low), forked (medium), contributed (high).
3. Import to Clay. Use Clay's built-in GitHub enrichment to pull company, bio, and website. Filter immediately: remove profiles with no company data and fewer than 50 followers. This alone cuts the list by 30–40% and removes most students and inactive accounts.
4. Waterfall enrich for email: PDL first, then Hunter.io, then Snov.io. For LinkedIn URL plus phone, add RocketReach or Lusha as a final layer.
5. Score and segment: High-intent tier = forked or contributed, company size more than 20, seniority at senior level or above. Mid-intent = starred, company size 10–200. Sequence them differently — high-intent gets a direct technical ask referencing the specific repo; mid-intent gets educational content first.
6. Validate and push: Run through ZeroBounce, filter anything below 0.7 confidence, push to your CRM with repo name and signal type as custom fields. That context matters when your SDR goes to write a first line.
The whole thing takes about three hours to set up for a new repo the first time, 30 minutes for subsequent runs. I run a fresh extract monthly on each target repo — stargazer lists grow, and there are always new profiles to enrich.
What I actually use
For most GitHub prospecting today: GitHub API for extraction, Clay for enrichment orchestration, PDL as the primary enrichment source, Hunter.io for fallback email patterns, and ZeroBounce for validation before any send.
Phantombuster is genuinely worth it if you're running this for a non-technical teammate — setup is 10 minutes and the CSV output requires zero code to produce.
Apollo has a GitHub integration, but in my tests it didn't support fine-grained repo targeting and the enrichment just pulled from Apollo's database rather than doing real GitHub signal analysis. ZoomInfo has no GitHub-native workflow at all.
If you're also building pipeline from Twitter or Facebook developer communities alongside this workflow, Ziwa has been faster for me than PDL's direct API for resolving social handles to contact data — worth a look if those channels are part of your mix.
The full stack costs roughly $0.15–0.40 per enriched, validated contact depending on which enrichment sources fire. At that cost, with reply rates I've consistently seen in the 10–15% range on well-targeted lists, it's the most efficient outbound channel I've found for reaching developers who actually evaluate infrastructure and tooling.
Top comments (0)