GitHub Email Acquisition: Getting First Users for Open Source SaaS

2. 1. The Four GitHub Targeting Segments

Not all GitHub users are equal targets. The quality of a lead depends on the specificity of the signal. Here are the four segments ranked from hottest to coldest:

Segment A: Issue Openers with a Specific Complaint (Hottest)

Someone who opened an issue on a competing repo saying "please add X feature" or "I need Y but it's behind a paywall" is telling you exactly what they want. You built it. The email writes itself. Find issues on competing repos that describe your product's key differentiator.

How to find them: Go to the competing repo's Issues tab. Filter by closed issues with labels like "enhancement", "feature request", "question". Read the pain. Find email via your GitHub email extraction service.

Volume: Low (50-200 per repo). Conversion rate: Highest (5-15%).

Segment B: Contributors to Competing or Adjacent Repos

Someone who submitted a PR to a competing project is deeply invested in the problem space. They care enough to write code for it. They are often frustrated by the project's direction, maintainer responsiveness, or commercial decisions (especially post license changes). A fresh open source take is exactly what they have been waiting for.

How to find them: Go to the competing repo's Contributors page. Also check forks -- people who forked and actually committed to their fork are especially warm. Extract emails.

Volume: Medium (100-500 per repo). Conversion rate: High (3-8%).

Segment C: Stargazers of Competing Repos

Starred = interested but not yet committed. They know the problem exists and they bookmarked a solution. If you offer something better (open source, cheaper, self-hosted), many will switch. The email needs to be concrete about the specific improvement -- "starred Listmonk? I built the drag-and-drop email editor it never shipped."

How to find them: Competing repo's Stargazers list. Sort by most recently starred -- recent stargazers are actively evaluating solutions right now. Extract emails.

Volume: High (1,000-50,000+ per repo). Conversion rate: Lower (0.5-2%). Still worth it at scale.

Segment D: Maintainers and Authors of Related Projects

Someone who built a related tool -- even a small one -- understands the space deeply. They may want to contribute, collaborate, or simply be an early user who gives you useful feedback. This is less about conversion and more about recruiting early advocates who will star your repo and share it with their audience.

How to find them: Search GitHub for repos with related topics/keywords. Filter by repos with 50-500 stars (small enough to be builder-run, large enough to have real users). Look at the README author.

Volume: Low (20-100). Conversion rate: Variable. One good contributor is worth 100 passive users.

3. 2. The Tone That Does Not Sound Like Outreach

Developers receive a lot of cold email. They have a finely tuned radar for "founder doing growth hacking." The emails that work read like a message from a peer, not a pitch deck. Here is what separates them:

What works

• One specific reference to something they did. Their issue number, their PR, their repo name, a quote from their comment. Not "I saw you're interested in [topic]" -- that is generic and obviously automated. "You opened issue #234 on Listmonk 8 months ago asking for a drag-and-drop editor" is specific and shows you actually looked.
• Admit you built it for yourself first. "I got frustrated with the same thing and just shipped it" is honest and relatable. Developers respect builders who scratch their own itch. It is the origin story they trust.
• Ask for feedback, not a conversion. "Would you be willing to try it and tell me what's broken?" is a request developers are happy to fulfill. "Sign up for our SaaS" is not. The first email should never ask them to pay. It should ask them to look.
• Short. 3-5 sentences. No bullet points. No bold text. No signature with 4 social links. Plain text preferred. It should look like it was typed, not generated.
• From a personal email, not a company domain. "alexis@" is better than "hello@company.com" for the first message. It signals a person, not a marketing machine.

What kills these emails

• Opening with "I hope this email finds you well" -- instant delete.
• Describing your tool in marketing language ("powerful", "seamless", "robust").
• A CTA that requires account creation before they can see anything.
• More than one ask in the email.
• Mentioning funding, team size, or company name prominently.
• HTML email with a logo and footer -- screams newsletter.

4. 3. Email Templates by Segment

These are starting points, not copy-paste templates. The specific reference is the whole game -- fill it in precisely for each person and the rest almost does not matter.

Template A: Issue Opener

Use when: they opened a feature request or complaint on a competing repo that your product addresses.

Subject: re: issue #[number] on [repo]

Hey [name],

You opened issue #[number] on [repo] about [specific pain point] -- [repo] never shipped it and closed the issue. I had the same frustration and built [tool] around that exact gap. It's open source: [github link].

Would you be willing to try it and tell me what's still missing? Even a "this doesn't work for me because X" is useful.

[your first name]

Why it works: The subject line references their specific issue. They will open it. The body is 4 sentences. No pitch. Just: here is the thing you asked for, will you look at it?

Template B: Contributor to Competing Repo

Use when: they submitted a PR or contributed to a competing or adjacent project.

Subject: [repo] contributor -- question

Hey [name],

Saw your [PR / contribution] to [repo] -- [one specific thing you noticed about their work, e.g., "the caching fix was clever"]. I've been building something in the same space that takes a different approach: [one sentence on the key difference, e.g., "fully self-hosted, MIT license, no per-seat pricing"].

Repo is here: [github link]. Curious what you think, especially given what you know from [repo]. Would love your take.

[your first name]

Why it works: You referenced something specific they built. You asked for their opinion, not their business. Developers who contribute to OSS like being asked to evaluate technical work -- it is flattering in the right way.

Template C: Stargazer of Competing Repo

Use when: they starred a competing repo. Least specific, so the hook needs to be concrete about what your version does differently.

Subject: [competing repo] -- built the thing it never shipped

Hey [name],

You starred [competing repo] at some point -- I did too, but it never got [specific missing feature: drag-and-drop editor / self-hosted mode / flat pricing / etc.]. So I built that version: [github link].

Worth a look if [competing repo]'s [specific limitation] was the thing stopping you from using it seriously.

[your first name]

Why it works: The subject line is curiosity-driven and specific to what they already starred. The body is 3 sentences. You are not selling anything -- you are telling them the gap got filled.

Template D: Maintainer of a Related Project

Use when: they built something adjacent and you want a collaborator or early advocate, not just a user.

Subject: [their repo] + [your repo]

Hey [name],

I've been using [their repo] for [specific use case] -- really clean approach to [specific thing you genuinely liked]. I'm building something adjacent: [your repo], which [one sentence on what it does differently].

Thought there might be some overlap. Would be curious if you see any, and whether it's something that could be useful for [their repo]'s users.

[your first name]

Why it works: You led with genuine praise for their work, not your pitch. You are exploring overlap, not asking them to switch. This often turns into a collaboration, a shoutout in their README, or a contribution -- all of which are worth more than a $29/month subscription.

5. 4. Target Lists for Each Open Source Play

For each of the 30 open source plays from the TrustMRR analysis, here is the exact GitHub targeting strategy: which repos to mine, which segment to prioritize, and what the email hook should reference.

6. 5. Sequencing and Volume

Week 1-2: Segment A only (issue openers)

Start with the 50-100 most specific leads: people who opened issues on competing repos describing exactly your product's value proposition. Write each email manually. These are not automated sends -- each one should reference the specific issue number and quote a line from what they wrote. This is the segment where a 10% response rate is achievable. You want 5-10 people who will actually try the tool and give you feedback in week 1.

Week 3-4: Segment B (contributors)

Mine contributors to the top 3-5 competing or adjacent repos. Reference their specific contribution. At this point you have early feedback from issue openers and can say "I've been iterating on it with a few people from the [competing repo] community" -- which is social proof that costs nothing and feels genuine because it is true.

Month 2: Segment C (stargazers) at scale

Once the product is solid enough to survive first impressions from strangers, start the higher-volume stargazer emails. These can be more templated but still need the specific hook (which repo they starred and what your tool does differently). Send 20-50/day. Do not batch 500 at once -- you want time to respond to the replies that come in.

Ongoing: Segment D (related maintainers)

These are relationship emails, not acquisition emails. Send them continuously, 5-10 per week. The goal is to build a network of adjacent OSS maintainers who will reference your tool when relevant. One "check out this related project" in a popular repo's README is worth 1,000 cold emails.

Follow-up rule

One follow-up, 5-7 days later, maximum. Shorter than the first email. Something like:

"Just following up in case this got buried. [link] -- still happy to give you early access if you want to try it."

Two emails total. Never three. Developers who did not respond to two emails are not interested right now. Pushing harder turns a future convert into someone who associates your project with spam.

7. 6. What Kills These Emails

Mistake 1: Extracting email and sending within the hour

If someone starred a repo today and gets an email from you tomorrow, it feels like surveillance. Wait a few days, or better, target people who starred it 2-6 months ago -- they are still in the evaluation phase, not mid-hype.

Mistake 2: Generic personalization

"Hi [name], I saw you're interested in developer tools" is worse than no personalization. It signals automation while pretending to be personal. The specific reference to their exact issue/PR/repo is the only personalization that matters.

Mistake 3: Asking them to sign up before they can see anything

The first click from a developer email should go to your GitHub repo, not a landing page with a "Start Free Trial" button. They need to see code before they trust you. The GitHub repo is the landing page. The landing page is for converting people who already trust you.

Mistake 4: Emailing from a company domain with HTML formatting

"noreply@yourstartup.com" in an HTML template with your logo is a newsletter. Send plain text from your personal address. The goal is to look like a developer emailing a developer, not a startup running a campaign.

Mistake 5: Sending to everyone on a star list

Many GitHub profiles have no email, or have emails that bounce, or belong to bots and throwaway accounts. Filter before sending: look for profiles with a real name, a bio, and recent activity. 50 real leads are worth more than 500 unfiltered addresses.

Mistake 6: Not replying fast when someone responds

A developer who responds to your cold email within 24 hours is genuinely interested. If you take 3 days to reply, that window closes. Set up a dedicated inbox for these responses and treat them as your most important emails. One engaged early user who gives real feedback is more valuable than 100 passive signups.