The Employer-Concentration Read: Elephant Factor Before You Adopt a Dependency

Before you add a library to your stack, you want to know one thing that bus-factor and adoption-readiness scores do not answer: which companies pay the people who keep it alive, and what happens when the dominant one leaves or relicenses. This guide is for engineering managers, technical founders, and architects who have to defend a dependency choice. It turns the CHAOSS Elephant Factor and organizational-diversity metrics into a repeatable procedure that runs from a package name to a defensible single-vendor capture-risk tier, including how to clean noisy affiliation data before you trust the count.

What employer concentration actually measures

Employer concentration is the degree to which one company's payroll controls a project's code, and the metric that captures it is the Elephant Factor: the minimum number of companies whose employees perform 50% of the commits. A value of 1 means one company alone produces half the code. If 50% of community members are employed by the same company, that company is the elephant in the room.

This is a different question from the one most dependency guides answer. Bus factor counts distinct humans who keep a project alive. Adoption-readiness grades maturity and momentum. Neither tells you what a captured project actually poses: if all or most contributions come from one company, the project may not survive a strategy shift, an acquisition, or the company pulling its employees.

The Elephant Factor was coined by Bitergia and presented at OSCON 2015, inspired by the Apache Pony Factor, which finds the lowest number of committers whose contribution constitutes the majority of the codebase. The Pony Factor counts people. The Elephant Factor counts the companies behind them. That single change of unit is the whole point of this read.

Alongside Elephant Factor, track Organizational Diversity: how many different organizations are involved and how involved they are relative to one another. Elephant Factor gives you a single integer for the concentration; Organizational Diversity gives you the shape of the distribution behind it.

What captured dependencies do when the backer moves

A captured dependency fails in one of two ways: the dominant vendor relicenses or abandons it, or a thin volunteer crew simply runs out of hours. Both are documented, and they look opposite on a commit graph, which is why you must screen for both.

The relicense case is HashiCorp Terraform. In August 2023, HashiCorp changed Terraform's license from MPL 2.0 to the Business Source License v1.1, which restricts competitive use, with the BSL converting back to MPL only four years after each release. Terraform had broad adoption; that did not save it. The community forked it as OpenTofu, drawing over 100 companies, 10 projects, and 400 individuals pledging support, placed under the Linux Foundation. Then, in 2025, IBM acquired HashiCorp. Diversity in the contributor base did not prevent a single copyright holder from flipping the license.

The abandonment case is Ingress-Nginx. In March 2026 the project retires: no further releases, bugfixes, or security updates, with repositories made read-only. The cause was the opposite of corporate capture. It had only one or two people doing development work on their own time, and efforts to find additional support failed. This matters because Ingress-Nginx was critical infrastructure for roughly half of cloud-native environments. A low Elephant Factor here would not have flagged the risk; a maintainer count would have.

FFmpeg is the volunteer-under-pressure case. The project is sustained almost entirely by volunteers despite powering Chrome, Firefox, and YouTube backends, and the imbalance between the demands of global corporations and a small community maintaining complex code has never been clearer. Rails is the high-concentration-but-healthy case: Shopify employs about a third of the Rails Core Team and built Ruby's YJIT compiler, yet the project remains diversified enough to function. Concentration is a risk factor, not a verdict.

The lesson across these four: your tier has to flag both the dominant vendor and the empty bench.

The exit path that looks staffed on paper but is not

An alternative existing is not the same as an alternative being staffed. When you document an exit path, measure whether the market has actually moved to it, because talent and mindshare migrate far slower than a fork announces.

The clearest evidence is the Terraform fork itself. In Refolk's index of professional profiles, US professionals self-identifying with Terraform outnumber those listing OpenTofu by roughly 1,141 to 1, two-plus years after the fork.

Read this as a capture-lag signal. The OpenTofu backer list is impressive, but the pool of engineers who identify with the fork is tiny. If you plan to rely on the fork as your contingency, you are betting on a labor market that has barely formed. That does not make the exit path invalid; it makes it expensive, and you should price the migration cost accordingly in step 8.

This is also why an employer-attribution map is worth building before you adopt, not after you are stuck. Knowing which companies employ the maintainers of both the incumbent and its alternatives tells you where the real capacity sits. Refolk lets you ask for exactly those people in plain English and get back current employers across GitHub, LinkedIn, and the open web, which turns a manual affiliation hunt into a single query.

The procedure from package name to risk tier

Run these eight steps in order. Budget roughly a day of analyst time for a mid-sized project, plus a couple of hours from an engineering manager or architect to set the tier and exit path. The identity merge and employer attribution are where most of the time goes and where most of the errors hide.

There is a defensible order disagreement worth naming. CHAOSS pairs Elephant Factor with Organizational Diversity and Organizational Influence, and suggests starting with Elephant Factor, then Organizational Diversity, then Organizational Influence to see which orgs hold leadership positions. Some practitioners check governance and leadership before counting commits, on the logic that a single copyright holder makes the commit distribution moot. Both are valid; the sequence above computes first and governance-checks in step 7, but if you are screening many dependencies fast, a governance pre-filter saves work.

Cleaning the affiliation data before you trust the count

Data cleaning is load-bearing here, not cosmetic. Commit identities are noisy, and the noise moves the Elephant Factor by whole integers, so a project can look single-vendor or diverse depending entirely on whether you cleaned first.

The documented pipeline is CHAOSS GrimoireLab with its identity component SortingHat. People use different email addresses when committing to git repositories, so identities must be merged or the metrics will be incorrect. SortingHat groups found identities into unique merged identities algorithmically, relates each individual to one or more affiliations for different time periods corresponding to their employers, and exposes a manual web interface for the cases the heuristics get wrong. Its default matching keys are email, name, and username, and it puts everyone it cannot affiliate into an explicit bucket labeled "Unknown".

The enriched field to work from is the author organization: the organization to which the author is affiliated, where the same author can carry different affiliations over non-overlapping time periods. That time-bounded design matters, because attributing today's employer to a commit made three jobs ago is a false positive.

Why this deserves so much care: nearly 25% of open-source projects have one code contributor, and 94% have ten or fewer. When the whole contributor list is that short, a few unattributed personal-email committers can move the Elephant Factor by a full integer. On the other end of the distribution, five developers are responsible for packages generating 96% of supply-side value, and the top 1% of packages account for 80% of downloads, so the packages most worth this scrutiny are exactly the ones concentrated enough to be fragile.

One structural problem you cannot clean away: AI is degrading the metric itself. Elephant Factor gets noisier as more contributions arrive without a meaningful affiliation behind them at all, from bots, agents, and personal-domain emails. The raw factor is trending upward-biased, which makes projects look more diverse than they are. Hand-verification of the top contributors is now mandatory, not optional.

How this read goes wrong

Most bad employer-concentration reads fail in one of seven documented ways. Each has a tell and a fix, and every one of them can flip your tier, so screen for all seven before you sign off.

The bot problem is subtler than it sounds. The metric reports the same number for one engaged maintainer and one departed maintainer whose token still works. Automated commits keep flowing after a human has left, so a project can post healthy contribution volume while its actual bench has emptied. This is precisely how Ingress-Nginx got to a one-or-two-person reality, and it is why the tier in step 7 has to flag under-staffed community projects, not just dominant vendors.

The license blind spot is the most expensive one to miss. Healthy commit diversity does not prevent a copyright-holding vendor from relicensing. Terraform did it despite ecosystem breadth. Contribution spread and legal control are independent variables. A contributor license agreement or a single copyright holder can flip the license regardless of the Elephant Factor, so your governance cross-check in step 7 is not a formality.

Turning the numbers into a defensible tier

The tier is the deliverable, and its job is to survive an architecture review. Map the Elephant Factor to a base tier, then adjust for the failure modes that the raw number cannot see.

Use this base mapping, then apply the two overrides below it:

• Elephant Factor of 1: single-vendor, high risk. One company's employees produce half the code. Treat a relicense or a headcount pull as a live scenario.
• Elephant Factor of 2: concentrated, medium risk. Two companies carry the majority; you have one backup, not a community.
• Elephant Factor of 3 or more: diverse, lower risk on the concentration axis, but still check maintainer count and governance.

Two overrides push a tier up regardless of the factor. First, governance: if a single entity holds the copyright or requires a contributor license agreement, raise the tier, because the license can flip no matter how the commits are spread. This is the Terraform override. Second, staffing: if the total active-maintainer count is one or two, raise the tier even at a high Elephant Factor, because the project can die from exhaustion rather than capture. This is the Ingress-Nginx override.

The Rails case is the useful calibration point. Shopify employs about a third of the Rails Core Team, which reads as concentrated, yet the project stays diversified and functional, and Ruby Central holds an explicit principle to never become overly dependent on any single company or funding source. Concentration plus healthy governance plus a broad bench can still be an adopt. The tier is a judgment supported by numbers, not the number alone.

Building the employer side of that judgment by hand is slow, because you are chasing current employers across profiles that go stale. This is where asking directly beats scraping: Refolk resolves maintainers to their present employers across public sources, so the attribution map in step 4 and the exit-path staffing check in step 8 come from one query instead of an afternoon of cross-referencing.

Verify before you sign off

Run this checklist before you attach a tier to your name in a review. Each item maps to a failure mode above, and skipping any one of them is how a defensible tier becomes an indefensible guess.

Keeping the read current

An employer-concentration read has a shelf life, because both the payroll behind a project and the market for its alternatives move. Re-run the read on a cadence, and re-run it immediately on a trigger.

The natural triggers are the events in the case table: a relicense announcement, an acquisition of the dominant backer, or a public maintainer-shortage notice. HashiCorp's relicense and IBM's later acquisition are the pattern to watch for; either event should push you back through steps 4 through 8 the same week. A maintainer stepping down publicly, as in the Ingress-Nginx retirement, is the abandonment-side trigger.

Between triggers, refresh the employer attribution and the exit-path staffing on a routine cadence, because affiliations change quietly. The capture-lag signal from Refolk's index is the reminder here: an exit path that existed on paper for two-plus years still had a labor market roughly 1,141 times smaller than the incumbent. Re-checking who actually works on the alternative, and where, is what turns a paper contingency into one you can execute. Ask for those people, confirm their current employers, and update the tier. That keeps the read something you can defend, not a snapshot that quietly went stale.