No, not by definition. A developer who puts an email on their public GitHub profile has chosen to be reachable there. What turns a legitimate message into spam is what you do with that: a template that could have been sent to a thousand people, a sequence of five follow-ups, an opt-out that does not work, or an address you took from a git commit rather than from the profile. Commit emails are the line most teams cross without noticing: they appear in public history as a technical artefact of how git works, not as an invitation. One specific message to a profile address, with your real name and an easy way out, is normal professional contact and is treated as such.
What developers actually object to
Read any thread where engineers complain about recruiters and the grievance is remarkably consistent. It is almost never "you contacted me". It is that the message shows no sign the sender looked at anything: the wrong language, the wrong seniority, a role in a city they left four years ago, a first line generated from their job title.
The second grievance is the sequence. One message that misses the mark is forgettable. The same message four more times, each pretending to be a friendly nudge, is what makes people write the thread.
The address you should not use
Every git commit carries an author email, and on public repositories that history is readable by anyone. It is tempting, because it exists even when the profile shows nothing.
It is also the clearest way to get treated as a scraper. That address ended up in public because git records it, not because anyone decided to publish it; GitHub even offers a noreply address specifically so people can keep it private. A recruiter who writes to a commit address has answered the question "was this published for me to use" with a no, and the reply, when it comes, reflects that.
The profile email is different in kind. It sits in a field labelled public email, on a page the person controls, and it can be removed in one click. That is a decision, not an artefact.
What a message that gets answered looks like
The specific reason is not a courtesy, it is the entire message. If you cannot name what this person built and why it matters for the role, there is nothing to send. And if you can, the message writes itself in four lines.
Worth keeping in mind: only 14% of developers in our index signal that they are open to opportunities. The overwhelming majority of good replies come from people who were not looking, which is exactly why the reason has to be about their work rather than about your role.
Volume is the variable that decides everything
One message a day to people you actually chose is a different activity from two hundred a day from a list. The rules recognise this too: GitHub's Acceptable Use Policies prohibit using public information to send unsolicited bulk email, and CAN-SPAM's obligations are built for senders operating at volume.
The practical test is simple. If the message you are about to send could go to any of the other names in the list without editing, you are sending spam, whatever the tooling calls it.
Where this answer does not hold
Some communities are hostile to any recruiting contact regardless of how the message is written, and a few maintainers say so explicitly in their profile or their repository. Respect that: it is stated, and ignoring it costs far more than the one reply you were hoping for. The same applies to anyone whose profile says no recruiters.
Frequently asked questions
Is it legal to email someone from their public GitHub profile?
In the EU this is normally done under legitimate interest, with a privacy notice and a working right to object. In the US, CAN-SPAM asks for a real sender, a postal address and a functioning unsubscribe. Legality is not the hard part; volume is.
How many follow-ups are acceptable?
One follow-up, at most, and only if the first message had a specific reason. A developer who did not answer a well-targeted message is not going to answer the same message with more urgency attached.
Can I use the email from a developer's git commits?
You can technically read it, and you should not use it. It is in public history because git records the author of a commit, not because the person published it as a contact address. GitHub provides a noreply address precisely so it can stay private.
What should the first message contain?
Your real name and company, the role, one specific sentence about something they actually built, where you found them, and a way out that works on the first click. Four lines is enough and shorter is better.
Fewer names, each worth a real message
Search by what people build, so the specific reason is already in front of you when you write.
Try StarHunt for free