SovereigntyGap.
SovereigntyGap.sovereignty-gap.eu

Family 4 · ~10 min read

Contribution concentration

Cases that demonstrate that modern open source is dominated by salaried contributions from a few companies — foundation "neutrality" is a legal convention, not real independence.

Theses illustrated 05 · 08 · 11

The imaginary of open source rests on the image of a community of passionate volunteers contributing in their free time. That imaginary, fixed by Eric Raymond in The Cathedral and the Bazaar in 1999, no longer corresponds at all to today’s industrial reality. The cases that follow show that modern open source is a mode of industrial coordination dominated by a few companies — the “neutrality” of foundations is a legal convention, not operational independence.

The Linux kernel — 84.3% of commits by paid employees#

Data date : 2025 Status : continuous trend since ~2010 Manifesto theses illustrated : 5, 6, 8, 11

The fact#

According to the Linux Foundation’s annual reports and Linux Weekly News (LWN) analyses, more than 80% of contributions to the Linux kernel today come from developers paid for that work. In 2025, that figure reaches 84.3% of commits, distributed across more than 1,780 contributing organisations. Intel remains the leading contributor by changeset volume, followed by Google; Intel and AMD together account for 17.4% of commits. Kernel version 6.18 saw 2,134 developers contribute in a single cycle, a historical record. Individual unpaid developers represent only a marginal fraction of the lines of code modified on recent LTS versions.

What it demonstrates#

This figure is probably the most structuring datum of the contemporary open source debate. It invalidates three commonly mobilised narratives:

  1. The myth of the volunteer. Critical open source is no longer produced by enthusiasts; it is produced by salaried employees. Passion may exist, but it is framed by the priorities of employers.

  2. The myth of community neutrality. When 84% of contributions come from paid employees, the technical roadmap mechanically reflects the priorities of the companies paying. This is not a conspiracy, it is the arithmetic of working time.

  3. The myth of the easy fork. Forking a project maintained 84% by salaried employees requires either replicating their payroll (impossible for most states or non-profits) or accepting an immediate impoverishment of development pace.

This does not disqualify the Linux kernel — which remains one of the most international and best-governed open source projects — but it disqualifies the idea that using it suffices to constitute a sovereign posture.

Sources#

Kubernetes — Capture by contribution capacity#

Date : since 2014 Status : ongoing Manifesto theses illustrated : 4, 5, 12

The fact#

Kubernetes stems from an internal Google project named Borg, reimplemented in 2014 then donated to the CNCF in 2015. From its creation until today, Google remains the dominant contributor, followed by Red Hat (IBM since 2019) and Microsoft. Technical governance reflects this concentration: steering committees and SIGs (Special Interest Groups) are populated mostly by employees of these same companies. Precise contribution statistics are published in real time on the project’s DevStats portal.

What it demonstrates#

Kubernetes illustrates how a project “donated” to a foundation remains structurally controlled by its former owner and its direct competitors. European actors who contribute to Kubernetes do so marginally in quantitative terms, which removes any capacity to inflect the roadmap. This dynamic feeds directly into the mechanism described in thesis 12: European providers adopting Kubernetes become distributors of a grammar whose definition lies beyond their reach.

An alternative reading exists and deserves mention: a liberal economist could reply that this concentration is not “capture” but a natural effect of Google and its competitors doing the work and no one else doing it. This objection is valid descriptively. The manifesto does not reject it — it draws the political conclusion: if Europeans want to influence these standards, they must devote to it the contributive mass that does not exist today.

Sources#

  • Kubernetes contribution statistics via DevStats : https://k8s.devstats.cncf.io/
  • CNCF Annual Report.
  • Mathilde Pannier (IFRI, December 2022), Software Power.

Chromium — 90% of commits by Google#

Date : since 2008 Status : ongoing Manifesto theses illustrated : 5, 6, 12

The fact#

Chromium is the “open source” project that forms the base of Chrome, Edge, Brave, Opera, and virtually every modern browser apart from Firefox and Safari. In 2024, Google contributed 94% of the project’s commits (more than 100,000 commits over the year), a figure published by Google itself. The project’s technical direction, its roadmap, its release cadence are entirely controlled by Google.

In January 2025, Google and the Linux Foundation announced a joint initiative named Supporters of Chromium-based Browsers, aiming to diversify contributions to the project. Microsoft, Meta and Opera joined. The announcement comes at a time when the US Department of Justice is examining the possibility of forcing Google to divest Chrome under antitrust proceedings — the initiative can also be read as preparation for a possible operational decoupling between Chrome and Chromium.

What it demonstrates#

Chromium is the extreme case of mono-sponsor open source. Its licence (BSD) is free. Its governance is not. Competing browser vendors based on Chromium cannot inflect its development; they can only diverge on the user-interface and telemetry layer. This explains why every “alternative” Chromium-based browser looks alike: they depend on the same core, and that core serves Google’s needs first.

Sources#

Android Open Source Project — Open in law, closed in practice#

Date : since 2008 Status : ongoing, evolving restrictively Manifesto theses illustrated : 4, 5, 12

The fact#

The Android Open Source Project (AOSP) is legally open source: its source code is published under Apache 2.0. But its technical direction is entirely controlled by Google, which decides on the publication schedule, the integrated features, and which components are released (AOSP) or kept proprietary (Google Mobile Services, Play Store, related services). The actual functional forks — LineageOS, GrapheneOS, /e/ — remain marginal and require considerable maintenance effort to fill what Google does not release.

What it demonstrates#

AOSP is the textbook case of a project where a free licence coexists with massive operational dependency. For a smartphone manufacturer to produce a genuinely usable phone, it needs Google Mobile Services, which are not open source. This modernised “embrace, extend, extinguish” strategy was used to turn an open operating system into infrastructure whose useful layer is closed.

Sources#

VS Code and VSCodium — When telemetry devours the auditable#

Date : since 2015 Status : ongoing Manifesto theses illustrated : 5, 7

The fact#

Microsoft publishes Visual Studio Code’s source code under the MIT licence. But the binary officially distributed by Microsoft on vscode.dev contains telemetry, and uses a closed proprietary Marketplace of extensions whose access Microsoft controls. VSCodium is the truly free fork, compiled without telemetry and without proprietary marketplace — but it cannot access the official marketplace, which constitutes precisely the editor’s value-in-use. VSCodium therefore remains marginal in usage terms.

What it demonstrates#

This case illustrates a subtle strategy: open the code, close the ecosystem. The licence is free, but value-in-use is concentrated in a service operated by the original owner. It is open source whose apparent sovereignty masks a massive usage dependency.

Sources#

Kubernetes by the numbers — Mapping corporate contributions#

Date : entered the CNCF in March 2016; analysis as of April 2026 Status : ongoing Manifesto theses illustrated : 6, 8, 11, 12

The fact#

Kubernetes is the flagship project of the cloud-native ecosystem. According to the CNCF 2024 annual survey, 80% of organisations use Kubernetes in production (against 66% in 2023, an annual growth of 20.7%), and the entire container orchestration ecosystem has largely standardised around Kubernetes. The project has passed every CNCF maturity level: graduated since 6 March 2018, the first CNCF project to reach that status.

This centrality makes the mapping of contributions to Kubernetes a structural indicator of the cloud ecosystem’s technological sovereignty. And that mapping, from the start, has been North American.

The CNCF’s public Kubernetes Project Journey Report establishes the following figures:

  • Before entering the CNCF in March 2016: Google and Red Hat (IBM since 2019) accounted for 83% of contributions to the project.
  • At the time of the report’s writing (2023): these two companies still accounted for 46% of cumulative contributions.
  • More than 7,800 organisations have contributed to Kubernetes since its entry to the CNCF.
  • The other structural contributors explicitly cited by the report are Microsoft, Amazon, Intel (all American) along with US midsize companies such as Meetup, Weaveworks, Mattermost.

The report mentions no European company among its structural contributors. The public dashboard k8s.devstats.cncf.io confirms that European companies appearing in contribution statistics (SUSE, Canonical, more marginally a few others) do not reach the order of magnitude of the major North American contributors.

Regional comparison. According to the analyses published by CNCF DevStats, the geographic distribution of contributors (and not of contributing companies) to Kubernetes is more balanced than the corporate distribution: Europe represents a substantial share of individual contributors to the project. But this individual European presence is largely carried by employees of US companies’ European subsidiaries (Google Munich, Microsoft Berlin, Red Hat Brno, AWS Dublin) rather than by employees of European companies contributing as such.

The CNCF Japan analysis published by Cloud Native Community Japan in February 2025 (on DevStats 2024) and in March 2026 (on DevStats 2025) provides a comparable reading for Japan: 93 Japanese contributors in 2024, 36 in the kubernetes/kubernetes repository alone in 2025, with an overall decline in the absolute number of Japanese contributors year-on-year. The same rigorous analysis applied to Europe would let us precisely quantify the European position. It remains to be conducted and would be valuable evidence for this dossier.

What it demonstrates#

The distinction matters. Technically, contributions are made by people and the quality of the code does not depend on the employer. From the sovereignty standpoint, however, the criterion is the capacity of a European organisation to influence the roadmap, arbitrate technical choices, and sit on governance bodies. That capacity is not measured by the number of European individuals who contribute, but by the number of European companies who employ those contributors and give them an institutional mandate.

The concentration of corporate contributions to Kubernetes among North American companies has several consequences that European providers should document in their Sovereignty Profiles:

  • Roadmap arbitrated outside Europe. The structuring evolutions of Kubernetes — API models, security models, privileged integrations, architectural choices — are arbitrated by major contributors. At this level, Europe is observer rather than arbiter.

  • Dependency on North American strategic orientations. Strategic shifts by Google or Red Hat in their respective Kubernetes investments have a disproportionate impact on the project’s trajectory. If one of these companies decided to scale back its commitment, the project’s dynamics would be directly affected.

  • Information asymmetry on vulnerabilities. Security embargo processes favour major contributors (see family 2 — Kubernetes / CNCF).

  • Limited fork capacity. In the event of a major flip (CNCF governance change, hypothetical relicensing, strategic fork by a dominant player), European providers would have a reduced capacity to maintain a Kubernetes fork independently, for lack of accumulated in-house expertise.

None of these consequences is, taken in isolation, catastrophic. They are, however, structurally worrying for an ecosystem that has made Kubernetes its standardisation foundation and that claims technological sovereignty. Filling this contribution deficit is a European public policy that does not exist today and would deserve to be put in place — for example, via a European fund dedicated to direct funding of maintainers on critical cloud-native bricks, or via documented upstream contribution requirements in public procurement.

Sources#

Opening to OSS health reports#

The ecosystem of open source health measurement — the CHAOSS project (Community Health Analytics for Open Source Software), hosted… by the Linux Foundation — produces yearly indicators of contribution concentration, bus factor (the minimum number of people whose disappearance would jeopardise the project), and geographic diversity. These indicators systematically show massive corporate concentration on central projects.

The Synopsys / Black Duck Open Source Security and Risk Analysis Report (OSSRA), published annually, documents that about 80% of the code in modern applications consists of open source components, of which a critical fraction is maintained by fewer than 5 people. This figure intersects contribution concentration and supply chain fragility (see family 6).

Sources#

→ Related operational commitments#

Contribution concentration has only one lasting antidote: that other actors — user companies, independent foundations, European public and private investors — in turn fund the maintenance of the projects on which they depend.

Full catalogue of commitments →

Read the manifesto →