# The Upstream Investment Map: Category Repos to a Quarterly Shift Brief

*Start from a named technical category and produce a one-page quarterly brief of entrants, ramps, and exits, each with a measured error rate and the threshold it cleared.*

- Canonical URL: https://www.refolk.ai/guides/upstream-investment-map-quarterly-brief
- Pillar: Market and talent intelligence
- Format: Playbook
- Published: 2026-10-30
- Last reviewed: 2026-10-30
- Reading time: 23 min
- Keywords: measure corporate contributions to open source by employer, open source contributor affiliation analysis, track competitor investment in open source projects, organizational diversity elephant factor by quarter, who controls an open source project by company, which companies contribute to an open source project

## Key takeaways

- Automated email-domain affiliation labelled 92.0% of TensorFlow commits correctly but only 39.5% of Transformers commits, so the attribution error rate has to be measured for each repo before any company share is published.
- Hand-label every contributor with 5 or more commits, then score a random sample of 100 commits per repo, so each repo gets a measured error rate rather than an assumed one.
- Google and Red Hat's combined share of Kubernetes contributions went from 83% before CNCF to 35% and then 46% while their raw counts kept rising, so a ramp call needs raw counts moving the same way as share.
- No public source publishes the normal quarter-over-quarter swing for a top contributing company, so shift thresholds must come from your own baseline and must also exceed the repo's measured attribution error.
- Kubernetes caps any one company at one third of its 7 steering seats, so on capped bodies seat share cannot follow labor share and measures influence only below the cap.
- In Refolk's index, only 124 US and 47 German profiles carry an open source maintainer headline, so maintainer seats must come from OWNERS and MAINTAINERS files, with profiles used only to resolve employers.

This playbook is for strategy teams, talent-intelligence analysts, and operators who need to know which companies pay engineers to build the open-source projects that define their category, and which of those companies started ramping up or pulling out this quarter. It takes you from a named technical category to a frozen repo set, then to employer-attributed activity with a measured error rate, and ends in a one-page brief of entrants, ramps, and exits. Every call in the brief carries a confidence grade and the threshold that triggered it.

## What does an upstream investment map answer?

An upstream investment map shows which companies supply the labor and which hold the control seats across every repo that defines a category, quarter by quarter, and which of them changed course. It is competitive intelligence about where rivals and partners spend engineering money. It is not a risk check on a single dependency.

If your question is whether one library you depend on relies too heavily on one employer, use the [single-dependency concentration guide](https://www.refolk.ai/guides/employer-concentration-elephant-factor) instead. This document picks up where that one stops. It covers many repos, follows them over time, and ends in a decision someone in strategy has to make. The questions it settles:

- Which companies started paying people to work on the category's core repos this quarter?
- Which incumbent cut its review effort, even though its commit count looks flat?
- Who holds the approver seats, and does that match who does the work?
- Is a company's rising share real investment, or are other companies leaving?

The deliverable is a one-page brief, dated and tied to a repo-set version. It has three lists (entrants, ramps, exits) plus a short watch list. Each line names the company, the metric that moved, the raw counts next to the share, the threshold it cleared, and a confidence grade.

Two things are deliberately left out:

- **Dashboard leaderboards as output.** Foundation dashboards are inputs. They show rolling or lifetime totals and grade nothing.
- **Composite influence scores.** CHAOSS describes Organizational Influence as a measure of "the amount of control an organization may have in a project," built from several other metrics, but publishes no formula for it. This playbook builds control from seat counts you can audit yourself.

**How long it takes:** no public source gives a time for any stage of this work, including the minutes per manual affiliation lookup. Time each stage on your first quarter and use those numbers as your budget. Later quarters cost much less because the affiliation file carries over.

## Which signals show control, and which only show labor?

Commits and reviews show labor. Approver and maintainer seats show control. Comments and issues show interest. Keep these three in separate columns from the first table to the last, because blending them is how a company that files a lot of issues ends up described as a major investor.

#### Upstream signal layers, control to interest

1. **Governance seats** - Steering and technical committees, often capped per company
2. **Approver and maintainer seats** - OWNERS and MAINTAINERS entries that gate what merges
3. **Reviews and merges** - Paid maintenance labor on other people's code
4. **Commits and PRs** - Feature and fix labor, easiest to inflate
5. **Comments and issues** - Interest and usage, counted as contribution by some dashboards

*The higher a layer sits, the more a company must sustain to hold it; comments and issues prove interest, not investment.*

The split matters because the most widely published counts mix all the layers together. In DevStats, "Contributor" means "anyone who made a review, commented, committed, or created a PR or issue." That definition suits community health work and misleads in investment analysis. The CHAOSS Organizational Diversity metric points in a better direction: among its suggested measures is "% of merges/reviews from each organization," which is closer to paid maintenance labor than raw commits are.

Control is recorded in files and rosters, not in activity. In Kubernetes, "OWNERS files assign the reviewer and approver roles used in the two-phase code review process." Approvers decide what merges, so a company's count of approver entries across the category's OWNERS or MAINTAINERS files is the most direct control signal you can audit. LFX contributor leaderboards also show a "Maintainer" tag, which is useful as a cross-check. My research did not establish per-employer seat rules for CODEOWNERS or MAINTAINERS files at other foundations, so read each project's governance document before you interpret its seat counts.

Governance caps limit what control signals can show. The Kubernetes steering committee allows "a maximum of one-third representation from any one company at any time." If job changes or acquisitions push a company over that limit, members must resign until it is met again. Steering has 7 seats, and one roster included 2 Google members, which is under the cap. Steering candidates also need endorsements from three voters at three different employers. On a capped body, seat share cannot follow labor share, so it shows influence only up to the cap. A company that triples its labor will not triple its steering seats.

| Metric | What it proves | How it lies |
|---|---|---|
| Commit share | Who writes code | Consumer emails hide the employer |
| Review or merge share | Who pays for maintenance | One reviewer can swing a small repo |
| Approver seats | Who gates merges | Lags labor; capped bodies stop tracking it |
| DevStats contributor count | Who shows up at all | Counts comments and issues |
| Elephant Factor per quarter | How concentrated labor is | Lifetime value misstates the present |
| New organizations | Who entered | A rename or acquisition looks like entry |

Elephant Factor is the concentration number you will be asked for most often. CHAOSS defines it as follows: choose a percentage threshold, then add up each company's contributions from largest to smallest until the total reaches the threshold. The number of companies you needed is the factor. The CHAOSS worked example comes out at 2. The LFX Organization dependency widget uses the same idea with a 51% threshold: it highlights "the group of organizations whose contributors performed 51%+ of all contributions in the selected time period." Homebrew shows 1 organization at 59%. Zephyr shows 7 organizations accounting for 53%, with 644 others behind them.

> **Rule:** Elephant Factor 1 means concentrated
>
> State the direction in every brief: a lower Elephant Factor means fewer companies do the work. Part of the CHAOSS knowledge-base prose describes a high value as heavy reliance on a few, which contradicts its own formula.

Labor and control together sort the companies in a category into four positions. Plot each company once per quarter, and the movement between quadrants becomes the story the brief tells.

#### Labor share against control seats

Horizontal axis runs from Low labor share (commits plus reviews) to High labor share. Vertical axis runs from Few approver or maintainer seats to Many seats.

| Quadrant | What it means |
| --- | --- |
| Seats without labor | Check for inherited or acquired seats; expect seat losses at the next OWNERS cleanup |
| Steward | Treat as the category's owner; any drop in reviews is headline material |
| Bystander | Track only for entry; one hand-labelled contributor here is an early entrant signal |
| Labor without control | Ramping or hired-in labor; watch for approver promotions in the next two quarters |

*A company's quadrant tells you what to watch next quarter; movement across a boundary is a brief-worthy event.*

## How accurate is automated employer attribution?

Automated employer attribution can be good or nearly useless depending on the repo. The same email-domain method labelled 92.0% of TensorFlow commits correctly and only 39.5% of Transformers commits. You cannot assume one error rate for a whole category; you have to measure it for each repo.

The best public evidence comes from a study of co-opetition in PyTorch, TensorFlow, and Transformers. It took affiliation from commit email, which it calls "the most accurate source of affiliation data." Commits from consumer email addresses, or with no email address, were left blank. Three authors cross-validated the affiliation of every contributor with 5 or more commits and filled missing values by hand through internet searches. Contributors with fewer than 5 commits were dropped to keep the labelling work manageable. Accuracy was then scored on 100 randomly sampled commits from each project.

| Repo | Automated correct | Implied error |
|---|---|---|
| PyTorch | 83.9% | 16.1% |
| TensorFlow | 92.0% | 8.0% |
| Transformers | 39.5% | 60.5% |

The error column is derived as 100 minus accuracy.

**39.5% - Commits correctly attributed by automated email matching on Transformers**

The same method reached 92.0% on TensorFlow, so a category-wide error assumption would be wrong by a factor of more than two on one repo.

The likely cause is how the hosting company's contributors handle email. If many of them commit from consumer or no-reply addresses, their commits come back blank and the hosting company's share is understated. The hosting company is usually the one strategy cares most about, so this is the worst place to be wrong. Treat that cause as likely rather than proven, and confirm it on your own sample.

A second distortion runs the other way. In the study, contributors who used both a company and a private email had all their commits linked to the company. That rule is reasonable in a snapshot. In a time series, it credits someone who left and kept committing from a personal address to their old employer, unless you apply employment date ranges (Step 5 below).

### Unknown is not the same as independent

Unknown and independent are different findings and need separate rows. The study kept two buckets: people who did not work for a company were recorded as "volunteers," and affiliations it could not identify as "unknown." DevStats reports independents as a named row. In one year of CNCF DevStats data, Red Hat led with 194,699 contributions, Microsoft had 107,645, Google 91,158, and Independent came fourth at 52,404.

There is no published typical unknown share and no published convention for reporting unknowns. My convention: print the unknown share next to every company share, never fold it into Independent, and do not make a call on any company whose movement is smaller than that repo's unknown share.

## The procedure: from category repos to a quarterly shift brief

The procedure has eight steps, run in order every quarter: freeze the repo set, pull events, label automatically, clean up by hand and measure the error, apply date ranges and acquisitions, compute by quarter, apply shift rules, and publish. Cleanup comes before any reading of trends. The CHAOSS practitioner guide lists "Identify Trends" first, but its own Step 2 begins "once you've cleaned up the organizational affiliation data," and that order is the right one.

#### Category repos to quarterly shift brief

1. **Freeze the category repo set** - List the repos that define the category from the foundation landscape and LFX project pages, with a reason for each. Done means a frozen list with a version date that every later number cites.
2. **Pull quarterly activity per repo** - Collect commits, PRs, reviews, and issues with timestamps per repo and quarter, from DevStats or git. Done means one event table with comments and issues kept as their own event types.
3. **Run automated affiliation** - Map email domains to organizations and leave consumer, no-reply, and missing emails blank. Done means every event carries an org label or an explicit blank.
4. **Clean up by hand and measure the error** - Hand-label every contributor with 5 or more commits, then score a random 100-commit sample per repo. Done means a measured error rate stored next to each repo's data.
5. **Apply date ranges and acquisitions** - Give contributors employment date ranges and map acquired companies to acquirers from the close date forward. Done means no event is credited to a company before it employed the person or owned the employer.
6. **Compute metrics by quarter** - Compute raw counts and share for commits and reviews, approver seats, quarterly Elephant Factor, and new organizations. Done means a company-by-quarter table with a raw count beside every share.
7. **Apply shift rules and grade each call** - Compare each movement with your own baseline band and the repo's measured error, then label entrants, ramps, and exits with a grade. Done means every call records its threshold and grade.
8. **Publish the brief and re-run last quarter** - Publish the brief with the repo-set version and error rates, then re-run the previous quarter after the next affiliation import. Done means a dated brief plus a correction note if a prior call changed.

### Freezing the repo set

The repo set is the definition of the category, so it has to be frozen before you count anything. Add a repo when the category's buyers or builders treat it as core infrastructure and it appears in the foundation landscape or on LFX. Leave out demos, forks, and SDK mirrors. Write the version date at the top. If you add a repo mid-year, start a new version and recompute the baseline, because a new repo can produce an "entrant" that is really just a newly counted repo.

### Running the manual cleanup

Manual cleanup is the slow step. For each repo, sort contributors by commit count, take everyone with 5 or more commits, and resolve every blank or doubtful label. The lookup itself is the part that eats time: you have a name, a handle, and sometimes a consumer email, and you need the employer during the quarter in question. [Refolk](/) handles this as a plain-English request and returns the person's profile from GitHub, LinkedIn, and the open web, with employment history you can turn into date ranges. Then draw 100 random commits per repo, check each against your cleaned labels, and record the error rate. That number goes into the brief.

### Date ranges and acquisitions

Employment date ranges stop people's job moves from showing up as corporate strategy. CNCF's gitdm "supports mapping based on dates, to account for developers moving between companies," and DevStats "uses companies.yaml to map acquisitions, so data from an acquired company is assigned to the acquirer." Use the same pattern: one row per person per employer with a start and end date, plus an acquisition table mapping the acquired company to the acquirer from the close date forward. Events before the close stay with the acquired company.

> **Tip:** Re-run the last quarter after the next import
>
> gitdm affiliations reach DevStats about once every four weeks, and accepted gitdm fixes appear a couple of days later. Re-run the previous quarter after that import, and publish a correction if any call changes.

## Where does profile data help, and where does it mislead?

Profile data is good at resolving a known contributor to an employer and dating their job changes. It is poor at finding maintainers in the first place, because very few maintainers describe themselves that way. Take seats from OWNERS and MAINTAINERS files, and use profiles to fill in who employs the people listed in them.

In Refolk's index of professional profiles, the number of people who describe themselves as open-source maintainers in their headline is small. The number with open source program office (OSPO) titles is smaller still. An OSPO is the internal team that runs a company's open-source policy and upstream work.

| Segment | US | Germany | US:DE |
|---|---|---|---|
| "open source maintainer" headline | 124 | 47 | 2.6x |
| OSPO-type titles | 15 | 2 | 7.5x |
| Maintainers per OSPO title | 8.3 | 23.5 | - |

Source: Refolk's index at the time of sampling. Ratios are derived.

**124 - US profiles in Refolk's index whose headline says "open source maintainer"**

CNCF alone reports more than 300,000 contributors, so self-described maintainers are a tiny fraction of the people who actually hold maintainer seats.

Three practical conclusions follow from Refolk's index:

- **Seats come from files.** With 124 US and 47 German self-described maintainers, a headline search would miss almost everyone who holds approver rights. Parse OWNERS and MAINTAINERS files, then resolve each name to an employer.
- **Employer spread is wide.** Employers in a 25-profile US maintainer sample include Microsoft, AWS, Docker, Dynatrace, and Okta. The German sample includes Datadog, NVIDIA, IBM, and Dash0. A category map built only on the largest foundation members will miss the smaller names.
- **Missing OSPOs do not mean missing investment.** German maintainers outnumber German OSPO titles 23.5 to 1. German upstream work may run without a formal program office. That reading is unverified, so do not treat a missing OSPO as a sign of no upstream budget.

Profile searches also bring in noise. In Refolk's index, OSPO-title matches included U.S. Army South, ODNI, and an "Enterprise PMO Program Manager." These are open-source intelligence or generic program-office roles, not open-source software roles. Review every title match by hand before you count it.

The highest-value use of profile data in this playbook is catching job changes before the foundation affiliation files do. A reviewer who moved employers six weeks before quarter close will usually still carry the old label in that quarter's dashboard data.

Ask me this: `Kubernetes SIG Network reviewers who changed employer in the last six months` - [run the search](https://www.refolk.ai/start?q=Kubernetes%20SIG%20Network%20reviewers%20who%20changed%20employer%20in%20the%20last%20six%20months).

*Returns the named reviewers with their previous and current employers and approximate move dates, ready to drop into your date-range table.*

## How do you tell a real ramp from noise?

No public source publishes the normal quarter-over-quarter swing for a top contributing company, so every threshold has to come from your own baseline. A call must clear both that baseline and the repo's measured attribution error. Share alone never triggers a call; raw counts must move the same way.

The figures that do get published are cumulative changes since a project joined CNCF, not quarterly ones. They are still useful for one lesson: share and investment are different things.

| Project | Contributing companies, join to later | Change | Top-org share |
|---|---|---|---|
| Kubernetes | 731 to 8,012 | +996% | Google+Red Hat 46% |
| Cilium | 533 to 1,011 | +90% | Isovalent 90% |
| Helm | 930 to 1,314 | +41% | Microsoft 17% |
| etcd | 499 to 873 | +75% | CoreOS 36% |

Source: CNCF Project Journey Reports. The Kubernetes and Helm windows are older than the Cilium and etcd windows.

Kubernetes shows the trap clearly. Google and Red Hat together held 83% of contributions before CNCF, 35% in the earlier journey report, and 46% in the later one. Their raw contribution counts kept growing the whole time. A share-only reading would call that a pull-back followed by a ramp. In fact, the first move came from thousands of other companies arriving, and the second has to be checked against raw counts before anyone calls it new investment.

### Building the baseline

Build the baseline from your own history:

1. Back-fill at least four prior quarters with the same repo set, cleanup, and date ranges.
2. For each company in the category's top tier by raw count, record the quarter-over-quarter change in raw commits and raw reviews.
3. Set each company's baseline band to the largest absolute swing in that history. Where a company has too little history, use the largest swing among comparable companies.
4. Record the measured attribution error for each repo next to the band. A call has to clear the larger of the two.

These are my operating conventions, not published standards. Write them into the brief so a reader can disagree with the threshold rather than the arithmetic.

### Shift rules

- **Entrant:** an organization with no labelled events in the prior four quarters that now has events in at least two labor types (commits and reviews), with at least one contributor in the hand-labelled 5-plus-commit set. Check renames and acquisitions first.
- **Ramp:** raw commits or raw reviews rise beyond the baseline band and beyond the repo's error, with share rising in the same direction. A new approver seat strengthens the call.
- **Exit:** raw labor falls beyond the band for two consecutive quarters, after date ranges confirm the drop is not one or two people changing jobs. A lost approver seat strengthens the call.
- **Watch:** anything that clears the share threshold but not the raw-count one, or that depends on a single contributor's employer change.

### Confidence grades

- **High:** clears band and error in raw counts and share, holds for two quarters or is confirmed by a seat change, and survives the post-import re-run.
- **Medium:** clears band and error in raw counts and share for one quarter only.
- **Low:** within measured error, share-only, or resting on one person. Low calls go on the watch list, never into the three headline lists.

> A shift smaller than your attribution error is not a shift. It is a labelling artifact.

**Shift rule card (paste into the brief appendix)**

```
REPO SET: <name> v<date>    QUARTER: <Qn>    BASELINE QUARTERS: <list>
PER-REPO ERROR (100-commit sample): <repo>=<x%>; <repo>=<x%>
UNKNOWN SHARE PER REPO: <repo>=<x%>; <repo>=<x%>

ENTRANT  = zero labelled events prior 4 quarters
           AND events in commits AND reviews this quarter
           AND >=1 contributor with 5+ commits, hand-labelled
           AND not a rename or acquisition (checked: Y/N)
RAMP     = raw commits OR raw reviews up by > max(baseline band, repo error)
           AND share up in the same direction
EXIT     = raw labor down by > max(baseline band, repo error) for 2 quarters
           AND date ranges rule out individual job moves
WATCH    = share-only move, OR within error, OR depends on 1 person

GRADE HIGH   = clears rule in raw + share, 2 quarters or seat change, survives re-run
GRADE MEDIUM = clears rule in raw + share, 1 quarter
GRADE LOW    = anything else (watch list only)
```

*Fill the bands from your own back-filled quarters; leave the logic unchanged so calls stay comparable across quarters.*

## How does this analysis go wrong?

Most wrong calls in this kind of work come from attribution, not arithmetic. A company gets credited with work it did not pay for, or loses credit for work it did. Each failure mode below comes with the check that catches it.

> **Watch out:** Most "exits" are renames
>
> Before you publish any entrant or exit, check the acquisition table and employment date ranges. A company that seems to vanish while a new one appears with the same contributors has usually changed its name or been bought, not changed its strategy.

1. **Email-domain affiliation on company-hosted repos.** Transformers scored 39.5%, so the hosting company's share can be badly wrong. Looks like: the obvious owner of a repo shows a modest share and a large blank or unknown bucket. Check: score a random 100-commit sample per repo before you publish anything.
2. **Acquired companies kept separate.** The CNCF journey reports still show Isovalent at 90% of Cilium and CoreOS at 36% of etcd, although Cisco and Red Hat acquired them. My sources do not give the close dates, so look them up before you map anything. Looks like: an exit and an entrant in the same quarter with overlapping people. Check: a companies.yaml-style acquisition table keyed on close dates.
3. **Lifetime Elephant Factor.** CHAOSS warns that a lifetime value "may misrepresent the current level of organizational diversity." Looks like: a project that has had one dominant company for years still showing a high factor. Check: compute it per quarter only.
4. **Reading Elephant Factor backwards.** The CHAOSS prose contradicts its own formula. Looks like: a brief celebrating a factor of 1. Check: write "1 means concentrated" in the brief's legend.
5. **Stale affiliations.** gitdm refreshes about every four weeks (an older README says one to two times a month), so a job change near quarter close lands in the wrong quarter. Looks like: a ramp at one company and a matching dip at another, driven by the same few people. Check: re-run the previous quarter after the next import.
6. **"Contributor" includes comments.** DevStats counts comments and issues, so a company that files a lot of issues looks like it is investing labor. Looks like: a high contributor count with almost no reviews or merges. Check: split commits, reviews, and comments into separate columns.
7. **Keyword collisions in profile searches.** In Refolk's index, OSPO-title matches included U.S. Army South, ODNI, and an "Enterprise PMO Program Manager." Looks like: an OSPO headcount that does not match any known open-source program. Check: review every title match by hand.
8. **Rising share read as investment.** Google and Red Hat went from 35% to 46% of Kubernetes while their raw counts also rose, and share also rises when other companies leave. Looks like: a ramp call with flat raw counts. Check: print raw counts next to every share.

There is one more limit, and the evidence cannot remove it. Because no public baseline for quarterly variance exists, your first two or three briefs rest on a short history. Mark that in the header and expect thresholds to tighten as quarters build up.

## Publishing the brief and keeping it current

Publish one page per quarter, after the first affiliation import following quarter close. Lead with the calls, keep the method in an appendix, and put the repo-set version and per-repo error rates in the header so nobody has to ask how much to trust it.

**Quarterly upstream shift brief (one page)**

```
UPSTREAM SHIFT BRIEF | Category: <name> | Quarter: <Qn> | Repo set v<date>
Attribution error (100-commit sample): <repo> <x%>, <repo> <x%>
Unknown share: <repo> <x%>, <repo> <x%> | Elephant Factor (50%, this quarter): <n> (1 = concentrated)
Baseline history: <n> quarters

ENTRANTS
- <Company>: <commits n, reviews n, contributors with 5+ commits n> | trigger: <rule> | grade: <H/M/L>

RAMPS
- <Company>: commits <prev> -> <now> (share <a%> -> <b%>), reviews <prev> -> <now> | approver seats <prev> -> <now> | trigger: > <band or error> | grade: <H/M/L>

EXITS
- <Company>: raw labor <q-2> -> <q-1> -> <now> | rename/acquisition checked: <Y/N> | trigger: <rule> | grade: <H/M/L>

WATCH
- <Company>: <what moved, why it is not yet a call>

CONTROL VS LABOR
- Quadrant moves this quarter: <Company> <from> -> <to>

CORRECTIONS TO LAST QUARTER
- <call>, <what changed after re-run>
```

*One line per call; never drop the raw counts, the trigger, or the grade to save space.*

Keep the map current with a fixed rhythm:

- **Every quarter:** run the eight steps, publish, and then re-run the previous quarter after the next affiliation import.
- **When the category changes:** version the repo set, back-fill the new repo, and recompute baselines before you make calls on it.
- **When a big acquisition closes:** add it to the acquisition table at the close date and re-check every entrant and exit that involves either company.
- **Between quarters:** check job moves for the people who hold approver seats. A quick Refolk request for the reviewers in one SIG or maintainers file shows job moves weeks before the dashboards pick them up.

#### Before the brief goes out

- [ ] The repo set is frozen and its version date is printed in the header.
- [ ] Every repo has a measured error rate from a random 100-commit sample.
- [ ] Every contributor with 5 or more commits has a hand-checked employer label.
- [ ] Unknown and independent are reported as separate rows for each repo.
- [ ] Employment date ranges and acquisition close dates have been applied.
- [ ] Commits, reviews, and comments are in separate columns, and no call rests on comments or issues.
- [ ] Every share in the brief has its raw count beside it.
- [ ] Elephant Factor is computed for this quarter only and the legend says 1 means concentrated.
- [ ] Every entrant and exit was checked against renames and acquisitions.
- [ ] Every call names the threshold it cleared and carries a High, Medium, or Low grade.
- [ ] Last quarter has been re-run after the latest affiliation import, and any corrections are listed.

## Frequently asked questions

### How do I find which companies contribute to an open source project?

Start with commit email domains, since the most rigorous published study calls commit email the most accurate affiliation source. Then hand-label every contributor with 5 or more commits and leave consumer or missing emails blank. Foundation dashboards such as LFX Insights and DevStats give you a fast first look, but check their accuracy on a random sample of 100 commits before you trust company shares, because automated accuracy ranged from 39.5% to 92.0% across three major repos.

### Does an Elephant Factor of 1 mean a project is healthy or concentrated?

An Elephant Factor of 1 means the project is concentrated. One company alone does enough of the work to reach the threshold. The factor counts how many companies you need, largest first, to reach a set share of contributions, so lower means more concentrated. Part of the CHAOSS knowledge-base prose reads it the other way round, so say the direction explicitly in every brief and always compute it per quarter, never over the project's lifetime.

### Why not just use the LFX or DevStats organization leaderboard?

Leaderboards are good inputs but poor conclusions. DevStats counts comments and issues as contributions, affiliations refresh only about every four weeks, and acquired companies can show up under their old names. None of them grade a change or separate labor from control. Use the leaderboard to build your event table, then apply your own cleanup, date ranges, and shift rules on top of it.

### How many commits should a contributor have before I hand-label their employer?

Use 5 or more commits. That is the threshold the PyTorch, TensorFlow, and Transformers study used to keep manual labelling manageable while covering the people who do most of the work. No published source supports a higher cutoff such as 10. Below 5, leave automated labels or blanks in place, and make sure your 100-commit accuracy sample shows the error that remains.

### What counts as a meaningful quarter-over-quarter shift in company contributions?

No public baseline exists, so a meaningful shift is one that clears your own baseline band for that company and is larger than the repo's measured attribution error. On top of that, raw counts have to move the same way as share. If only share moves, other companies may simply have left. Treat a single-quarter move as medium confidence until a second quarter or a seat change confirms it.

### How do I tell who controls an open source project by company?

Count approver and maintainer seats by employer from OWNERS and MAINTAINERS files, and list governance seats separately. Do not use commit share for this. In Kubernetes, OWNERS files assign the reviewer and approver roles that gate merges. Some governance bodies cap representation, such as Kubernetes steering at one third per company, so seat share there shows influence only up to the cap.

---

*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/upstream-investment-map-quarterly-brief*