How do you contact GitHub stargazers?

Starring is a deliberate act. A developer was signed in, looked at a repository, and clicked a button that says this matters to me. Maybe it is your repo and they are evaluating it. Maybe it is a competitor’s repo and they are shopping the category. Either way, they raised their hand about the exact problem you work on, which is the one thing a purchased contact list can never give you.

Be honest about what the signal means, though. A star is interest, not intent. Some stargazers are bookmarking for a weekend project, some are students, some starred three years ago and moved on. Warm means you have a true reason to write, not that anyone is waiting to hear from you. For what a star does and does not tell you, see what a GitHub stargazer is. And recency matters: how fast stars decay explains why last week’s stargazer is worth ten from 2023.

Start with what GitHub gives you for free. Every public repo lists its stargazers at github.com/OWNER/REPO/stargazers. That page shows usernames and avatars, nothing more, so the manual work is clicking through to each profile and looking for three things:

• A public email. GitHub keeps email private by default, so you will only see one when the developer chose to show it. When it is there, it is your best channel.
• A website or blog link. Personal sites often carry a contact page or a reply-able newsletter.
• Social accounts. Many developers list X, Bluesky, LinkedIn, or Mastodon on their profile. A short, polite message there is a legitimate channel when no email exists.

Two things GitHub will not do for you: it has no direct messages, and the stargazers page has no export, no filters, and no company or role information. For a 40-star repo, clicking through by hand is an hour or two. For a 4,000-star repo it is not realistic.

That lookup is the part WarmStars automates. Paste a public repo URL and it scans the stargazer list into named profiles built from public data: name, company, role, social links, and a public email where one exists. Each email carries a confidence tier (verified, high, medium, or likely) so you know which addresses are safe to send to before you write a word. The email side is covered in how to find a stargazer’s email.

Three ingredients, all of them forms of respect for the reader’s time. First, reference the repo: it is the true, checkable reason you are writing, and it separates your note from the cold pitches already in their inbox. Second, give the why-now: they starred recently, you just shipped the thing people star you for, or you have one genuine question. Third, make one clear ask, and make it easy to decline. A question they can answer in one line beats a request for a 30-minute call.

Keep the whole message under 120 words. Here are two that follow the pattern. Both recipients are invented.

Notice what is missing: no feature dump, no fake flattery, no calendar link demanding Thursday at 2. Each message states the reason, the relevance, and a single low-pressure ask, then gets out of the way.

The same list, handled badly, burns your domain and your reputation at the same time. The failure modes are predictable:

• Bulk blasts. Exporting 3,000 addresses and sending one identical message to all of them is not outreach, it is spam with a thin excuse.
• Fake personalization. A templated compliment generated at scale reads worse than no personalization, because everyone has seen the template. When the merge breaks, it literally says big fan of your work on undefined.
• Guessed addresses. If someone did not publish an email, do not manufacture one. Guessing patterns burns deliverability and trust together.
• Ignoring opt-outs. Someone asking you to stop is the clearest possible signal. Continuing past it is the line between marketing and harassment, and in most places it is also the line the law draws.
• Pitching on GitHub itself. Opening issues, commenting on pull requests, or mentioning people to promote a product violates GitHub’s acceptable use rules and torches your name in the community. Keep outreach off the platform.

The etiquette is simple: use only what people published, tell the truth about who you are, make one relevant point, and stop the moment someone asks. Every email should carry a real unsubscribe or opt-out path that works, not a dead link at the bottom of a template.

The legal side in one plain paragraph: in the United States, CAN-SPAM requires a truthful subject line, your real identity and postal address in the message, and an unsubscribe you honor promptly. In the EU and UK, GDPR requires a lawful basis for using someone’s data; for relevant, low-volume business outreach that is usually legitimate interest, which in practice means the message must be genuinely relevant, you must tell people where you got their information, and you must stop and delete on request. Canada’s CASL is stricter than both. None of this is legal advice; check the rules where your recipients live.

WarmStars is built around the same posture: it reads public data only, and it honors a do-not-contact list automatically, matched by email and GitHub login, so a person who opted out never appears in your results in the first place.

Set expectations honestly. Cold outreach to a purchased list typically earns reply rates around one percent, often less, because the reader has no reason to care. Stargazer outreach starts from a real, checkable signal, so short, small-batch, hand-finished messages do meaningfully better: single digits to low double digits percent is a reasonable range to plan around. The caveat cuts the other way too: the more you automate the personalization out, the closer your numbers drift back to the cold-list baseline.

The volume math keeps you grounded. A 3,000-star repo typically yields a public email for 30 to 50 percent of stargazers, so call it 900 to 1,500 reachable people before you filter for fit. A well-chosen subset of a few hundred, at even a modest reply rate, is dozens of real conversations. This is a pipeline of relevant conversations, not a growth hack, and contacting recent stargazers first raises every number in that chain.

• Not everyone is reachable. Typically 30 to 50 percent of a repo’s stargazers published an email. Some of the rest list a social account, and some are simply unreachable. That is by design, and worth respecting.
• A star is not buying intent. Expect a share of just-bookmarking replies, and treat those people as future readers, not failed leads.
• GitHub gives you nothing built-in. No direct messages, no export, no company data, and its rules prohibit unsolicited promotion on the platform itself, so outreach happens off GitHub through channels people chose to publish.
• Small repos mean small lists. A 200-star repo might yield 60 to 100 reachable people. That can be a great week of conversations for an early product, but it is not a database.
• Opt-outs shrink your list over time. That is the system working as intended.

WarmStars handles the part that does not deserve your time: turning a raw stargazer list into people you can responsibly contact. Paste a public repo URL and a scan returns named profiles with company, role, social links, and a public email where one exists, all from public data. Two features matter specifically for outreach. Confidence tiers: every email is labeled verified, high, medium, or likely, so you can send to the top tiers and keep your bounce rate low, which protects your sending domain. And automatic opt-outs: anyone who asks not to be contacted lands on a do-not-contact list, and their row never reaches your exports, so that hygiene is not yours to maintain by hand.

WarmStars does not send anything. You export the list and write from your own tools, which keeps you in control of the message, the unsubscribe, and the pace. If you are a founder running your own outbound, the founder-led sales page shows how teams run this end to end. This guide covered the message itself; for the full motion from star list to closed deal, read how to turn GitHub stars into customers. The free plan includes two scans a month, and paid plans start at $39; see pricing.