# Developer Public Evidence: What Each Source Proves

*For any named engineer, you can find every public source that holds their technical evidence and judge what each one proves, how it lies, and how fresh it must be to count.*

- Canonical URL: https://www.refolk.ai/guides/developer-public-evidence-sources
- Pillar: Engineering and open source
- Format: Reference
- Published: 2026-08-12
- Last reviewed: 2026-08-12
- Reading time: 16 min

You have one engineer's name or handle and need to find their technical evidence across the open web. This is the cross-platform lookup for engineering managers, technical founders, developer-relations leads, and technical sourcers: it treats an engineer's public footprint as a set of evidence sources, and for each one it defines what the signal proves, how it misleads, and how fresh it has to be to count. Read it top to bottom once, then jump to the row you need.

Most guides read a single repository or score one GitHub profile. That is not the job here. The job is to look at whatever signal is in front of you, from any platform, and decide whether it is real capability, social proof, or a dead archive, and to confirm it belongs to the same person before you act on it.

## Which sources hold a developer's public evidence, and what each proves

Every public source exposes a different kind of metadata, and each kind proves a different thing. Below is the map: what the platform publishes, what that lets you conclude, and the one way it commonly deceives.

| Source | What it exposes | What it proves | How it misleads |
|---|---|---|---|
| GitHub commits | Author name and email in public-repo metadata | Authored code and collaboration behaviour | Stars are bookmarks, not attestation of quality |
| npm / package registry | `_npmUser` and `maintainers` name and email | Ownership of shipped, installable software | A pseudonym and a working email are all it requires |
| Stack Overflow | Reputation number and answer history | Past engagement with a problem domain | Points can come from questions or a few golden answers |
| Conference talks | Acceptance by a selection committee | Communication depth, third-party credentialing | The bullet is a claim; only the talk is evidence |
| Personal site / blog | Self-published technical writing | Depth and articulation on chosen topics | No external filter; anyone can publish anything |

Two rows deserve expansion because they are the load-bearing sources for developers.

GitHub is the anchor because Git uses your email address to associate your name to any commits you author, and once you push commits to a public repository the authorship metadata is published as well. That single fact makes commit email the strongest cross-platform identity key, covered in its own section below. But the popular counter, the star, proves almost nothing about the author. On GitHub, starring a repository adds it to the user's list of starred repos: it is a bookmark with a public counter, with no attestation that the starrer ran the code, read the source, or would recommend it.

npm and other package registries expose maintainer identity directly. `_npmUser` is an object containing the name and email of the npm user who published the package version, and `maintainers` is an array of author objects as listed in `package.json`. That is stronger than a star because publishing an installable package is a commitment, not a click. The catch: npm requires only a working email and username, and a pseudonym is allowed, so the identity attached to a package still needs anchoring.

Conference talks carry a credential most sources lack. Conference selection committees act as a third-party filter: a reviewer cohort read your abstract, ranked it against competing submissions, and chose yours. The talk is evidence; the resume bullet is a claim. That is why an accepted talk survives longer as proof than a self-published post of equal length.

> **Rule:** A counter is not a credential
>
> Treat any public number - stars, reputation, follower count - as a popularity signal until you have read the underlying artifact. The number tells you what got attention, never who did good work.

## The scarcity principle: why one Rust package outweighs one more Python repo

The evidentiary weight of any single artifact depends on how rare that skill's public footprint is. Scarce skills leave scarce traces, so one trace identifies a person far more sharply. This is base-rate mechanics, not a quality judgement.

In Refolk's index of professional profiles, 606 US-based software engineers list Rust as a skill, with top employers including Google, Oxide Computer Company, and Meta. The same index holds 55,822 US-based software engineers who list Python, with top employers including Google and Figma. A public Rust footprint is roughly 92 times scarcer than a Python one in the same market.

**92x - How much scarcer a public Rust footprint is than Python among US software engineers**

Refolk's index holds 606 US Rust engineers versus 55,822 Python engineers; scarcity multiplies how identifying a single artifact is.

Here are the two comparisons that make the point, straight from Refolk's index.

| Skill (US software engineers) | Count | Share vs Python |
|---|---|---|
| Python | 55,822 | 100% |
| Rust | 606 | 1.1% |

The same effect shows up across markets. The same title and skill, in two countries, produces very different pool sizes.

| Market | Rust software engineers | Ratio vs Germany |
|---|---|---|
| United States | 606 | 6.8x |
| Germany | 89 | 1.0x |

Germany's 89 Rust engineers cluster at employers like Helsing, Wolt, and Trade Republic. The practical read: when you find a public Rust crate tied to a personal domain, you have a much shorter list of people it could be than the equivalent Python repo would give you. Scarce skills make identity resolution easier and forgery harder, because there are fewer plausible collisions to rule out.

> Scarce skills leave scarce traces, and a scarce trace points at far fewer people.

## Commit email: the strongest cross-platform identity key

The one identifier that reliably links a developer across platforms is the git author email, because it is embedded in public commit metadata and is far harder to reuse by accident than a photo or bio. Anchor on it before you trust any softer signal.

Generic OSINT workflows lean on reused images and similar bios. Those are the weakest links you can pick, because they are trivially copied. The documented validation signals are reused images found by reverse image search, similar bios with reused descriptions and links, temporal patterns such as nearby registration dates, and cross-links where one account points to another network or a personal site. Useful, but soft.

For developers, the hard link is different. The git author email sits inside public commit metadata, and it often matches the npm maintainer email or the contact on a personal domain. When a commit email, an npm `maintainers` entry, and a personal-site contact all agree, you have an identity link no avatar can give you.

Two cautions keep this honest. First, a git author email can be set to anything locally, so an overlap can be forged; corroborate it with a verified account link or the GitHub `noreply` pattern. GitHub offers a `username@users.noreply.github.com` address precisely so developers can hide their real commit email, which means a missing email is not suspicious, just private. Second, when the strongest link is a soft signal only, say so and lower your confidence.

#### Identity signals ranked by how hard they are to fake

1. **Commit email overlap** - Embedded in public commit metadata; matches npm maintainer email or personal domain
2. **Verified account cross-links** - One platform explicitly links to another it controls
3. **Consistent bio and links** - Reused descriptions and outbound links across profiles
4. **Reused profile photo** - Same image found by reverse search; easily copied, so weakest

*Anchor on the hardest available signal, then corroborate downward, rather than trusting a reused avatar.*

## The procedure: from one handle to judged evidence

Work the seed identifier outward in seven steps, moving from enumeration to ownership to capability to freshness to lawful basis. The order below puts commit-email anchoring earlier than generic OSINT workflows do, because for developers it is more decisive than photo or bio matching.

#### One handle to judged, lawful evidence

1. **Fix the seed identifier** - Start from the one handle or name and turn it into a canonical string to pivot on. Treat it as a lead, not proof, since the same username can belong to thousands of people.
2. **Enumerate accounts across platforms** - Run a username sweep across many sites to collect candidate profiles. Automated tools return direct links in under 90 seconds; you end with a candidate list, not confirmed accounts.
3. **Validate ownership per profile** - Compare profile photos by reverse image search, reused bios, cross-links, and registration timing. Tag each profile high or low confidence and record the conflicting evidence.
4. **Anchor on commit-email overlap** - Pull public commit author email from GitHub and match it to the npm maintainer email or a personal domain. This is a hard link, but corroborate it because a local author email can be forged.
5. **Read each source for capability, not popularity** - On GitHub weigh merged PRs, tests, and maintenance cadence over stars; on Stack Overflow read top-voted answers, not the reputation number; watch a talk rather than trust the bullet.
6. **Score freshness** - Timestamp the last real contribution per source and discount cumulative-but-stale signals like star totals. Label each source current or historical.
7. **Establish lawful basis before contact** - Document legitimate-interest reasoning, link a privacy notice, and plan to notify within one month. You end with a defensible record before you send anything.

Sources disagree on order. OSINT guides put enumeration first; hiring-credibility guides start from portfolio review. Both are defensible, but for developers the commit-email anchor at step four is the decisive move, so do not let a generic tool push it to the end.

For step two, the enumeration tools are mature. One checks 732 platforms and returns profiles in under 90 seconds; another toolkit covers more than 400 sites, and a third covers more than 3,000. These give you reach, not truth, so everything they return enters step three as a candidate only.

Steps two through four are exactly where a plain-English search removes the most friction. Instead of sweeping a handle across hundreds of sites and reconciling the results by hand, [Refolk](/) lets you describe the person by the evidence they leave and returns matched profiles across GitHub, LinkedIn, and the open web.

I ran this search: `Developers in Berlin whose GitHub commits link to a personal domain and who answer questions on Stack Overflow about Kubernetes.` - [see the full result list](https://www.refolk.ai/s/9h8m4z1s20).

*Returns engineers whose public footprint already spans code, a personal domain, and Q&A history, so identity is corroborated before you start.*

## Freshness: how fast each signal goes stale

Not all signals age at the same rate, and the most dangerous ones never age at all. Score every source as current or historical by dating its last real contribution, and distrust any total that only accumulates.

The clearest trap is the GitHub star. Stars do not decay: the total is cumulative, so an 8k-star repo last touched eighteen months ago still looks impressive next to an 800-star repo shipped every week, yet recency of maintenance usually matters more than historical popularity. The signal that does count is maintenance cadence, because recently merged pull requests are a good sign that the project is actively being maintained and improved. Maintenance decays; the star total does not, which is exactly why the total misleads.

Stack Overflow is the sharpest case of a whole platform ageing out. Question volume collapsed from more than 200,000 per month in early 2014 to only 3,862 in December 2025, a 78 percent year-on-year drop, while 84 percent of developers now use AI tools daily per Stack Overflow's own 2025 survey. The mechanism is AI substitution. An active answerer profile today is rarer and older on average, so a reputation number proves past engagement far more than present activity.

| Source | Cumulative or decaying | Freshness cue to check |
|---|---|---|
| GitHub stars | Cumulative, never decay | Ignore the total; read the last-merged PR date |
| GitHub maintenance | Decaying | Recently merged pull requests |
| Stack Overflow activity | Sharply decaying | Date of the last upvoted answer |

Conference talks and published articles decay slowly as proof of communication and depth, because they are point-in-time selected artifacts rather than running activity. No source publishes a numeric months-until-stale threshold per platform, so that call is yours to make. A defensible default: treat GitHub maintenance older than a year and any Stack Overflow reputation not backed by a recent upvoted answer as historical rather than current.

**3,862 - Stack Overflow questions posted in December 2025**

Down 78 percent year on year from a 2014 peak above 200,000 per month, which turns most SO profiles into archives rather than live signals.

## How this goes wrong: false positives, source by source

Most bad reads come from a small set of repeatable failure modes. Each one below names the false positive it produces and the single check that defeats it. This is the part of the reference to keep open while you work.

**Handle collision.** The same username belongs to different people. Two unrelated developers both use "jdoe," and you merge them. Usernames are not unique identifiers, and popular handles can be reused thousands of times. Check: require a second overlapping signal, ideally a commit email, before asserting they are one person.

**Star worship.** You read a star count as a skill score. A viral awesome-list author with 467,820 stars looks like a systems expert. Stars reward solving a trendy problem, not strong engineering decisions, and commit counts and lines of code reward activity rather than correctness. Check: read merged PRs and tests, not the counter.

**Faked stars.** A repo is inflated by artificial starring. The star count is the most widely used popularity signal, but it is also at risk of being artificially inflated, which decreases its value for decisions. Check: look for anomalous lockstep or low-activity starring, the pattern published detection tooling is built to catch.

**Reputation inflation.** Stack Overflow points come from good questions or a handful of golden answers, not steady expertise. Even for users earning points mainly by answering, most of their answers receive no reputation points; the majority comes from a small proportion of golden answers. Check: read the specific top answers, not the number.

**Dead-archive signal.** A high reputation earned years ago reads as current mastery. Given the platform's collapse to a few thousand questions a month, it is usually historical. Check: date the last upvoted answer.

**Closed-source blind spot.** A strong engineer at a secretive employer leaves little public trace, and you mistake silence for weakness. Absence of GitHub is not absence of skill. Check: pivot to talks, published packages, and technical writing.

**Public-means-usable fallacy.** You scrape a public profile and contact freely. Public availability does not equal consent. Check: document legitimate interest and notify the candidate within one month, or delete the data.

**Committer-email spoofing.** A git author email can be set to anything locally, so an overlap you rely on may be forged. Check: corroborate with a verified account link or the `noreply` pattern before treating the email as an identity anchor.

> **Watch out:** The two failures that survive a careful reader
>
> Even careful practitioners fall for the dead-archive signal and the closed-source blind spot, because both are about what is missing. A stale profile and a silent one both look like data; date every signal and pivot when the trace runs out.

#### From candidate profiles to confirmed, current evidence

| Stage | Figure | Note |
| --- | --- | --- |
| Candidate profiles from sweep | 732 | Platforms a sweep can check |
| Same-person after ownership check | 400 | Sites a common toolkit corroborates |
| Anchored by commit email | 3000 | Sites a deeper tool covers for cross-links |

*Each stage discards profiles that fail a specific check, so only corroborated and current evidence reaches the send decision.*

## Contact fields, lawful basis, and the one-month clock

Finding a developer's contact detail is the start of an obligation, not the end of the search. Public exposure does not grant permission to use the data, and the load-bearing step is what you do after you find it.

Two field sources matter. GitHub publishes the commit author email in public-repo metadata once commits are pushed. npm publishes account data for the whole world to see on user pages and through the public registry, findable with commands like `npm owner ls`. Both are real contact routes, and both are governed.

In the EU, to process a candidate's personal data there needs to be a lawful basis, and for first contact where the candidate has not provided their information directly that basis will usually be legitimate interest. None of the alternatives, consent, contract, vital interest, public interest, or legal obligation, covers cold sourcing. But the regulator has repeatedly warned that public availability does not equal consent: you still need a lawful basis and must inform candidates what data you hold and why. And there is a clock. Send an email to sourced candidates informing them you are processing their data within one month, or delete their data.

> **Rule:** Notify within one month or delete
>
> When you source a candidate's data from any public source, tell them what you hold and why within one month of processing it. If you do not, delete the record. Public availability is never a substitute for a lawful basis.

**Legitimate-interest record for a sourced developer**

```
Candidate: [name or handle]
Data held: [commit email / npm maintainer email / personal-domain contact]
Source: [public GitHub commit metadata / public npm registry / personal site]
Lawful basis: Legitimate interest - recruiting outreach for a relevant open role
Balancing note: Data was published by the individual in a professional context; outreach is role-relevant and low-impact
Privacy notice link: [url to your candidate privacy notice]
First-contact deadline: [date data saved + 1 month]
Action if not contacted by deadline: Delete record
```

*Fill one per candidate at the moment you save their contact detail; keep it with the record.*

## Keep the read current: a verification checklist

Before you call an engineer's footprint mapped and act on it, run this checklist. It closes the gap between having found sources and having judged them.

#### Before you trust the footprint

- [ ] The seed handle is confirmed to one person by at least one hard signal, not the handle alone
- [ ] A commit email links GitHub to an npm maintainer record or a personal domain, and is corroborated by a verified cross-link
- [ ] GitHub was read on merged PRs, tests, and maintenance cadence, not on star count
- [ ] Any Stack Overflow claim rests on dated top-voted answers, not on the reputation number
- [ ] Each source is labelled current or historical by the date of its last real contribution
- [ ] A conference talk, if cited, is confirmed as accepted by a selection committee rather than self-listed
- [ ] A lawful-basis record exists with a privacy notice link and a one-month first-contact deadline

Two habits keep this reference from going stale on you. First, re-check the freshness thresholds against the platform itself, not against a remembered number: Stack Overflow's decline is ongoing, so query its public activity data before you weight a reputation score. Second, re-anchor identity whenever you add a source, because a new profile is another handle collision waiting to happen until a hard signal ties it in. The footprint you mapped last quarter is a snapshot; the developer keeps shipping, and so should your read.

## Frequently asked questions

### How do I confirm two profiles with the same username are the same person?

Treat the username as a lead, then require a second overlapping signal before asserting identity. The strongest confirmations are commit author email matching an npm maintainer email or personal domain, a reused profile photo found through reverse image search, consistent bios, and cross-links between accounts. Usernames are not unique identifiers and popular handles get reused thousands of times, so a shared handle alone proves nothing.

### What does Stack Overflow reputation actually prove?

Reputation proves past engagement, not current expertise. Points can be earned from asking good questions, and even for answerers most reputation comes from a small handful of golden answers rather than steady quality. With question volume down to 3,862 per month in December 2025 from a 2014 peak above 200,000, a reputation number is increasingly historical. Read the specific top-voted answers and check the date of the last upvoted one.

### Is finding a developer's public email on GitHub enough to email them?

No. Public availability does not equal consent. Even with data exposed in public commit metadata, you need a documented lawful basis, which for recruiting first contact is usually legitimate interest, and you must inform the candidate what data you hold and why. There is a clock: notify sourced candidates within one month of processing their data or delete it. Regulators have fined companies heavily for treating public data as free to use.

### How do I assess an engineer who leaves almost no public trace?

Absence of a GitHub profile is not absence of skill; strong engineers at secretive employers often keep their best work closed-source. Pivot to sources that survive a private employer: published npm or other package registry maintainer records, accepted conference talks with their committee credentialing, technical writing on a personal site or dev.to, and community discussion. Judge each on capability evidence rather than assuming silence means weakness.

### Why are GitHub stars a weak signal of engineering skill?

A star is a bookmark with a public counter, with no attestation that the starrer ran the code or would recommend it. Repos gain stars for solving a trendy problem, and some are marked to flag anti-patterns. Star totals never decay, so stale projects outshine actively maintained ones, and counts can be artificially inflated. Read merged pull requests, tests, and maintenance cadence instead of the number.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/developer-public-evidence-sources*