Mapping the Corporate Backers Behind an Open-Source Project

When a rival open-sources something, the public story is "community project." The real question a strategy team needs answered is narrower and harder: which companies are actually paying engineers to work on it, how concentrated is that funding on one vendor, and what does the pattern signal about intent. This guide is the end-to-end method for turning one project's public contribution graph into a ranked company-level map, a stated concentration number, and a defensible competitive read. It is written for strategy and research analysts and talent-intelligence teams who need to brief a decision, not run a community-health scorecard.

The method is not hard math. The hard part is the join between a commit and an employer, and the discipline of stating your assumptions so the number survives scrutiny. I will walk the full pipeline in order, give you the metrics with their published definitions, show where the read breaks, and hand you a checklist before you brief it.

What "corporate backing" actually means here

Corporate backing is the engineering effort companies fund on a project, measured by attributing contributions to the employers of the people who made them, then ranking and concentrating that by company. The output you want is a ranked table of companies, a concentration figure, and a governance read, not a list of individual usernames.

Three published metrics do the load-bearing work, all from the CHAOSS project's metrics catalogue. Define each once and use it precisely.

• Elephant factor: the minimum number of companies whose employees contribute a specified percentage of the total commits in a repository. It measures dependency on a small set of corporate contributors. The percentage is often set at 50% but this is not fixed.
• Affiliation Diversity: the ratio of contributors from a single company over all contributors. A sub-metric of Organizational Diversity, which expresses how many organizations are involved and how involved they are relative to one another.
• Organizational Influence: the ratio of contributors from each organization that has more than one contributor, over total contributors. CHAOSS notes it rolls close to elephant factor but is usually specific to one organization someone wants to avoid depending on.

There is no published numeric cutoff for "single-vendor." The practical read is qualitative: whether the work within a project is completed by people at a single organization or a small number. If most of the work is done by employees at one company, the project is riskier to use and harder to contribute to. Your job is to quantify the concentration and then make that judgement out loud.

The pipeline at a glance

The pipeline runs from a repository list to a one-page verdict in eight stages, and the order matters: deduplicate identities before you affiliate them to employers. Getting the sequence wrong inflates head counts and dilutes real vendor share.

The CHAOSS and GrimoireLab reference pipeline dedups first with SortingHat, then affiliates, then enriches. Some pipelines affiliate before deduping; I follow the CHAOSS order because merging identities first is what makes the per-company counts honest.

The step-by-step procedure

Run these eight steps in order. Timings assume one analyst working a single project of moderate size; the affiliation step dominates the schedule.

Time budget

The math is quick; the data cleaning is not. Plan for it.

Choosing the contribution unit

Count merged pull requests and review activity, not raw commits. A merged PR corresponds to a completed unit of work that passed code review and tests, which is far harder to game than pushing more commits.

The published critique is blunt: the problem with number of commits is that it does not tell you the value delivered, and like lines of code it is trivial to game by simply creating more commits. PRs-merged-per-engineer is a more useful signal because merging implies the work was reviewed and integrated. The best practice is a blend weighted toward reviewed work - merged PRs, review activity, and code ownership - rather than any single count.

Be careful how broadly you define "contributor." In CNCF's DevStats a contributor is anyone who reviewed, commented, committed, or created a PR or issue. That is fine for community health but too loose for an investment read, where you want people writing and reviewing code that ships. And beware automation: elephant factor gets noisier as more contributions arrive without a meaningful affiliation behind them at all, so filter bot and agent accounts before you count.

Resolving a contributor to an employer

This is where the read lives or dies. Affiliation almost always rides on the commit email domain, supplemented by profile affiliation and any on-behalf-of declarations, and the raw data is rarely clean enough to use as-is.

CHAOSS is explicit: the biggest challenge with identifying organizational influence is that affiliation data is almost never accurate enough to use without manual cleanup, because it most often comes from imperfect sources such as email domains. Contribution attribution is gathered primarily through volunteered information from contributors. Two concrete failure patterns follow from this.

• Default and reserved domains misattribute. The string codex@example.com uses a reserved domain that its apparent owner does not control, and it was claimed by an unrelated user, producing silent commit misattribution. Any personal or reserved domain can pin a corporate commit on the wrong entity or on nobody.
• Masked emails hide the employer. When a contributor enables email privacy on GitHub, the author email defaults to a no-reply address. That commit will look independent even if the person is on a vendor payroll.

There is one signal you can trust more: the on-behalf-of commit trailer. It requires the commit email and the organization email to be in a domain verified by the organization, so a valid on-behalf-of attribution is a strong claim of corporate authorship. Treat it as confirmation, not as coverage - most commits will not carry it.

The affiliation join is the single point of failure. The math is easy; the domain-to-employer table is where honesty is won or lost.

Before you aggregate, deduplicate. The documented tool is SortingHat, which maintains a database of contributor identities across Git, GitHub, Jira, and Slack, consolidates multiple raw identities into a single canonical Individual, and affiliates individuals with organizations over time-bounded enrollment periods. It can also consume gitdm files. This matters because a single person often uses several emails, and you must merge those usernames under one identity to get the right metrics. The effect is not published as a single figure, but the direction is certain: merging collapses inflated per-email head counts into fewer real people, which lowers apparent contributor totals and raises per-person and per-company concentration.

Once you have a clean company map, the follow-on questions are about people: who runs the open-source program at each backer, where the governance capacity sits, and who moved between the vendor and the fork. That is a plain-English lookup rather than another data-engineering project. When the map raises a name-level question, I can answer it directly - ask Refolk for the maintainers, program managers, or ex-employees behind a project and get them back with their public work attached, so the analyst does not rebuild the identity graph by hand.

The window changes the story

Compute concentration for both the trailing 12 months and the full project lifetime, because the window can invert the verdict. Organizational Diversity is designed to be assessed over various intervals for exactly this reason.

The load-bearing case is Kubernetes. Before it joined CNCF, the top two contributing companies, Google and Red Hat, accounted for 83% of contributions. Later, no single company dominates. A lifetime view banks those early founder-vendor commits forever and would still label the project two-vendor; a trailing view reflects who is paying engineers now, which is what a competitive read needs.

Governance is a separate axis from the graph

A diverse commit graph does not mean a project is safe from one vendor. Check governance and copyright separately, because who writes the code and who owns the right to relicense it are different questions.

The instructive contrast is legal, not statistical. Terraform was relicensed from MPL 2.0 to BSL 1.1, and the community forked OpenTofu under the Linux Foundation in response. That was possible because the copyright was aggregated. Compare the Linux kernel, which requires no copyright assignment, leaving thousands of copyright holders and making unilateral relicensing impractical. Structure predicts behaviour.

There is quantitative support, with a caveat. One study catalogued roughly 46% adverse events over eight years for concentrated-steward components, against about 2.5% for foundation-governed or distributed ones. That is a single study; verify it before making it load-bearing in a brief. Treat it as a directional prior, not a settled rate.

Context for how rare true distribution is: about 25% of open-source projects have a single developer, and 94% have ten or fewer. The XZ-Utils backdoor in 2024 targeted exactly such a lone-maintainer project. Concentration is the norm, not the exception, so a distributed, foundation-governed project is a finding worth stating plainly when you see it.

How this goes wrong

Most bad reads come from the same handful of mistakes, and each has a cheap check. Run these before you brief anything.

The two that catch experienced analysts are the threshold artifact and the window. On a fat-headed distribution, elephant factor crosses cutoffs steeply, so the same graph can read as 1 at a 50% threshold and 3 at 80%. The number is a policy choice; if you do not name the threshold, your reader supplies their own and your verdict becomes unfalsifiable. The window has the same property in the other direction - it can turn a maturing project into a false single-vendor alarm, as the Kubernetes case shows.

Where the people signal lives

The company map answers "who," but the governance capacity behind each backer is a people question, and the public signal for it is thin and worth reading directly. Open Source Program Office leadership is one proxy for how seriously a company invests in stewarding projects.

In Refolk's index, the distribution of that leadership is uneven across countries.

This is a small sample from a restrictive title filter, so treat it as directional rather than a population estimate. Column source: Refolk's index, titles including "Open Source Program Manager," "Open Source Manager," and "Head of Open Source," per country. The top US employers seen holding these titles include Sentry, Goldman Sachs, SAS, State Farm, and National Instruments - a reminder that OSPO investment is not confined to pure software vendors.

The engineer-level view is thinner still, which is itself the finding.

When you filter Refolk's index for US engineers who self-describe as open-source contributors or maintainers by skill, Kubernetes returns 2 people, with Intuit as the top employer seen, and Rust returns 0. The keyword filter is restrictive, so these are a floor rather than a count of the population. The lesson for your read is the same one that governs the whole pipeline: public self-identification undercounts real corporate investment, so the map you build from commits will almost always show more corporate effort than any title search will confirm.

Keeping the map current

A corporate backing map is a snapshot of who is paying engineers now, and "now" moves. Recompute on a cadence tied to your decision, not the calendar, and re-run the two checks most likely to have shifted: the trailing-12-month window and the governance policy.

Two things change fastest. First, contribution share, when a vendor ramps or pulls staff off a project, which the trailing window surfaces within a quarter or two. Second, licensing and CLA policy, which can change overnight and invalidate a "safe" verdict in a single announcement, as Terraform showed. Bot and agent volume is a third moving target; the mix of automated contributions is growing, and elephant factor gets noisier as unaffiliated automation arrives, so re-audit your bot filter each time.

Before you circulate any version of the map, confirm the following.

The deliverable is one page: a ranked company table, an elephant factor with its threshold, the two windows side by side, a governance verdict, and a single sentence of intent. If a reader can reproduce your concentration number from your stated unit, threshold, and window, the map will hold up in the room. If they cannot, you have written a community-health report, not a competitive read.