The Repository Provenance Signal Reference: Employer and Region

You are mapping who backs an open-source technology and where its contributors work and live, and you need to know which repository field tells you that and how each one lies. This reference is for strategy and research teams, talent-intelligence analysts, and operators sizing a market. It catalogs every repository-derived provenance signal, states what each one proves about a contributor's employer or geography, and names the specific way each one misleads, so you can jump to one row and leave.

Other guides in the library rank projects by traction, adoption curve, or momentum authenticity. This one is about the humans and organizations behind the code. Read it before you build a market map on a free-text location box or a personal Gmail address.

Which repository fields expose employer or geography

Git commit metadata and the GitHub profile carry a fixed set of provenance fields, and they are not equally trustworthy. Commit email domain, verified org membership, and a valid on-behalf-of trailer are the strong employer signals; timezone offset is a coarse geographic signal; the free-text location and company fields are the weakest.

Git records author name, author email, committer name, committer email, author date, and commit date, each stamped with a local timezone offset. On top of that, GitHub adds a free-text company field, a free-text location field, verifiable org membership, and the on-behalf-of trailer. GitHub notes you can read the email addresses of all publicly visible contributors and bots straight from the commit log, so the raw material is there for anyone who clones the repo.

Treat this table as the spine of the whole read. The rest of the guide expands each row into what to check and when to stop trusting it.

Commit email domain: the load-bearing employer signal

The commit email domain is the single most useful employer signal, because a corporate domain maps directly to an employer and appears on nearly every real commit. It is also the signal that self-destructs most quietly, so treat every domain as guilty until it survives three checks.

A domain lies in three ways. First, a corporate developer commits from a personal gmail or outlook address, and the domain map returns nothing, which tempts you to label them independent. Second, GitHub noreply addresses replace the real domain entirely. Accounts created after July 18, 2017 get a noreply address of the form ID+USERNAME@users.noreply.github.com, while accounts that enabled privacy before that date use USERNAME@users.noreply.github.com. A noreply address proves nothing about employer or geography, and treating users.noreply.github.com as a company is a real mistake people make. Third, web and merge commits collapse to the account's configured commit email, which defaults to noreply when privacy is on and, in that state, cannot be changed.

That third point produces the most systematic bias in the whole exercise. The commits most likely made on shared, managed, or browser-based machines carry zero domain signal, so web-heavy contributors look employer-less even when they work at a large company. A single account can also hold as many verified emails as the person wants, so one contributor may appear under several domains.

When you build the domain-to-employer table, flag every domain that is shared infrastructure (a personal-email provider), ambiguous (a consultancy or contractor domain), or noreply. Only a verified corporate domain with a stable presence across commits earns a high-confidence employer attribution.

Timezone offset: coarse region from every commit

The timezone offset is your best geographic signal because it rides on every commit, unlike the location field. It sketches large geographic areas, not cities, and it distorts in four documented ways you must correct before binning.

Git stores local time including the timezone tag in each commit, and when commits are merged the author time is usually preserved. Aggregated offsets therefore give an idea of large geographical areas. But the offset is not fine-grained, and it lies as follows.

• Half-hour zones get rounded. Researchers floor non-integer zones such as India's GMT+5:30 to the nearest lower integer, which blends India's +5 band into Pakistan's. Retain the raw offset before you bin so you can tell them apart later.
• DST shifts the offset seasonally. A contributor's offset moves twice a year. Do not read a one-off shift as a relocation; require a stable multi-month pattern.
• Travel drifts the offset temporarily. The same caution applies to short trips.
• Merge and rebase overwrite the tag. Some actions switch a commit to the timezone of the person performing the action, so separate the author offset from the committer offset.

Coverage is where timezone wins decisively. Every commit carries an offset, but in one large study only about 2.3 million of roughly 15 million accounts listed any location at all. A timezone histogram covers roughly six times more of the population than the location field.

Profile location and company: the weakest fields

The free-text location and company fields are self-reports in an open box, so they contain fiction and cover only a minority of accounts. Use them as a tie-breaker after timezone, never as the anchor of a geographic read.

The failure is well documented. In a large study of GitHub profiles, "The Future" geocoded to Palo Alto, "World Wide Web" was placed in Boston, and "/dev/random" was placed in India. A naive geocoder will happily convert a joke into a real city with real coordinates, and that city will silently pollute your market map. The fix is mechanical: reject any string that is absent from a gazetteer of real place names, and confirm every survivor against the contributor's timezone bin. If the geocoded location and the offset disagree, flag the row and trust the offset.

A free-text location field will turn a joke into a city with coordinates and put it on your map without complaint.

The company field carries the same free-text weakness plus staleness: it is a self-report that people update rarely, so it lags job changes by months or years. It is a hint about where to look for a domain or org signal, not a conclusion.

Verified org attribution and the on-behalf-of trailer

The on-behalf-of trailer is the only cryptographically strong employer attribution GitHub offers, and it is rare by construction. When present it is nearly conclusive; when absent it tells you nothing, so never treat a missing badge as evidence against corporate backing.

Four conditions must all hold for a valid trailer: you must be a member of the organization named in the trailer, you must sign the commit, your commit email and the organization email must both sit in a domain verified by the organization, and the commit message must end with the trailer on-behalf-of: @org <name@organization.com>. Each condition sheds users, so most corporate commits never carry it. The feature launched in public beta in March 2019 and is not available on GitHub Enterprise Server, which further limits where you will see it.

The related org-level signal is the Verified badge on an organization profile, which requires the profile website and email to match a DNS-verified domain. That badge tells you the org controls its stated domain, which in turn lets you trust that domain when you see it in commit emails.

This is the point in the work where matching a repo's contributors to real, current employers by hand becomes the bottleneck. Once you have a domain and a region for a contributor, you still need the person's present role and company, and the profile fields lag. Refolk closes that gap by resolving a role, skill, and place straight into named people, so you can move from "someone at a Rust shop in Germany" to an actual roster.

Repository-level signals of company backing

At the repository level, three signals separate company-backed from community projects: org ownership of the repo, a .github/FUNDING.yml sponsor file, and contributor concentration by email domain. Concentration is by far the strongest tell, and it is computable from email alone even when individual attributions are noisy.

Org ownership is a weak-to-moderate signal on its own, because plenty of community projects live under an org. The FUNDING.yml file lives in the .github folder on the default branch and configures the sponsor button; it supports up to four custom URLs, one org, and four sponsored developers, and it points at GitHub Sponsors, external platforms, or a custom funding URL. It tells you who is asking for money, not who is paying salaries.

Concentration is the discriminating measure. In host-company projects, employees account for roughly 80 percent of annual commits, while external companies contribute 10 to 20 percent. The published co-opetition study makes the pattern concrete.

Read this table as a range, not a threshold. A project where one domain supplies a majority of commits across multiple releases is company-backed. A project where the top domain supplies a fifth and the rest is spread wide is community-shaped.

The attribution procedure, end to end

Run the signals in a fixed order so that the strong ones anchor and the weak ones only ever confirm. The procedure below takes one analyst roughly a working day for a single repository, with a senior analyst reconciling at the end.

There is a genuine order disagreement in the literature: timezone-analysis practitioners treat the offset as the primary geographic signal, while profile-geocoding work starts from the location field. Treat them as cross-checks, not substitutes. The offset has the coverage; the location field, once cleaned, breaks ties.

How this goes wrong: failure modes and false positives

The single most valuable habit in provenance work is naming the failure before you trust the field. Every signal in this reference has a documented way of producing a confident wrong answer, and the fixes are cheap once you know to apply them.

Two more failures deserve their own paragraph because they operate at the project level rather than the contributor level.

Occasional domination looks like corporate backing. One company can briefly top an inactive repository's commits without backing it. In the OpenStack study, incidental single-company domination appeared in 32 of roughly 118 repositories, or 27 percent, without real corporate sponsorship behind it. A single-snapshot dominance read is a trap. Require sustained concentration across multiple releases before you call a project company-backed.

On-behalf-of absence is not absence of backing. This is worth repeating in the failure list because it is the error that most often understates corporate involvement. Most corporate commits never use the trailer, so its absence proves nothing. Never treat a missing badge as "not company-backed."

Turning attribution into a talent read

Once you have attributed contributors to employers and regions, the payoff is a talent map: which companies sit behind a technology and where the people who build it actually are. Geographic supply is lumpy, and that lumpiness sharpens your timezone priors.

In Refolk's index, senior Rust talent is markedly denser in the United States than in Germany, which matters when you read a Rust project's offset histogram and want to decide whether a European-looking band is signal or noise.

That is a 3.66x US-to-Germany ratio for senior Rust engineers, derived from the two counts. Skill density inside one market is lumpier still: Refolk's index holds 6,496 senior Go engineers in the United States against 1,243 senior Rust engineers, a 5.23x multiple, both clustered in the San Francisco Bay Area. A US-heavy offset band on a Rust or Go project is therefore a strong prior, not a coincidence.

The role itself is scarce. Refolk's index returns only 50 US profiles whose title contains "Open Source Engineer," "Maintainer," or "Program Manager," with top employers including Akuity, NVIDIA, Red Hat, and IBM. When you find the humans behind a project, they are a small, findable population.

Use the following rubric to convert your reconciled signals into a confidence level per contributor, so the market map you hand off carries its own uncertainty.

HIGH   employer: verified org membership OR valid on-behalf-of trailer OR corporate domain stable across releases
HIGH   region:   raw timezone offset stable 3+ months AND agrees with a gazetteer-valid location
MEDIUM employer: single corporate-domain commit, no org confirmation
MEDIUM region:   stable offset only, no location agreement
LOW    employer: personal email, self-reported company only
LOW    region:   noreply email or free-text location that fails the gazetteer
DROP           : noreply email with no other commits AND no offset signal

Keeping the map current

A provenance map is a snapshot of a moving population, so plan to re-run it rather than treat it as final. Domains change when people switch jobs, offsets shift twice a year with DST, and a project's concentration can swing across a single release cycle.

Re-verify on the cadence of the signal's own instability. Timezone bands drift seasonally, so re-check region reads after each DST transition rather than trusting a summer offset in winter. Concentration should be recomputed every release, because the OpenStack finding shows a single-snapshot dominance read is unreliable. Employer attributions built on a self-reported company field decay fastest of all and should be reconfirmed against a live source before you act on them.

The discipline that makes this reference worth keeping open is simple: name the lie before you trust the field. A market map built on a clean timezone histogram and concentrated corporate domains, with each weak field demoted to a cross-check, will survive scrutiny. One built on a free-text location box and a personal Gmail address will not.