6 min read

One does not simply fork into Mordor

Europe's digital autonomy takes more than Open Source
One does not simply fork into Mordor

Someone was wrong on the internet about European digital autonomy. Naturally, I had to check the data myself. What follows is either a public service or a cry for help, you decide.

The numbers don't lie

I recently analyzed asked Claude (Opus 4.5) about corporate contributions to the Linux Kernel 6.12 LTS, and the results are... let's say instructive: US companies account for approximately 52% of all contributions, while European companies contribute around 9%. Intel alone (9.3%) contributes more than all of Europe combined.

💡
Note: I've also quickly took a look at LF insights manually, and the order of magnitude is similar. The top 4 is Intel, RedHat, Google and Meta.

Ouch. If you want to all the numbers and not only for 6.12, it's here:

Linux Kernel 6.12 LTS - Regional Contribution Analysis

In an ideal world, Open Source shouldn't have borders. Code is code, freely available to everyone, and geography shouldn't matter. But surprise: we don't live in an ideal world, and these numbers raise uncomfortable questions about what "digital autonomy" really means for Europe (but this could apply to any place).

The money behind the code

This analysis tracks contributions by who paid the developers, not where the developers physically sit or what passport they hold. You can absolutely have an engineer based in Paris, working for Red Hat, contributing to the kernel every day.

But does that distinction actually matter for digital autonomy?

Here's the uncomfortable truth: if a US company decides to cut commercial support, stop security patches, or shift priorities away from features Europe depends on, what happens to that French engineer? They can quit or be let go first. But then what? Europe needs actual money to hire them somewhere else and continue that same work.

Can Europe suddenly fund 52% of Linux development? Even 20%? That's not exactly pocket change. Matching the combined investment of Intel, Google, AMD, Red Hat, Meta, NVIDIA, Oracle, and dozens of other US tech giants would require... well, let's just say a few espressos won't cover it.

Paying for developers is power over a project. Who could have guessed?

Open Source ≠ Open Knowledge

There's a common misconception that "open source" automatically means "no problem, we can figure it out." The code is open, sure. But consider what else matters:

  • Deep knowledge: of how the code actually works
  • Understanding of the roadmap: what's coming next, what's being deprecated
  • Influence over decisions: which features get prioritized, which architectures get supported
  • Security expertise: the ability to find vulnerabilities independently, without trusting someone else's audit

The fact that code is open is clearly a plus (vs closed code). But if nobody in Europe actually masters it, the open nature becomes almost irrelevant.

You can read the code, congratulations! But can you maintain it?

Can you fix a critical vulnerability at 2 AM when the US maintainers are asleep and your infrastructure is under attack?

"Just read the source code" is the "just learn to code" of infrastructure security.

This is the elementary basis of digital autonomy: you must have knowledge of the critical code in your infrastructure. And Linux is critical for a lot of infrastructure: from smartphones to cloud datacenters, from embedded devices to virtualization with KVM. It's basically everywhere, which is great until you realize you don't actually control it.

An alternative path: choosing your dependencies wisely

One strategic approach is to rely on projects where the balance of power is more favorable, or at least, less unfavorable.

This is one of the reasons Vates chose to build the XCP-ng virtualization stack on the Xen hypervisor rather than KVM. The analysis of Xen Project 4.21 reveals a dramatically different picture:

  • Europe leads Xen development at approximately 40-45% of contributions
  • Vates (France) currently holds the Release Manager role, with the power of directly influencing release cycles and priorities. The community manager is based in Annecy, France, a position we bootstrapped before the Linux Foundation picked up the tab. Europe is rising! ...One person at a time.
  • SUSE (Germany) has one of the most prolific committers in the project
  • Arm (UK) maintains all Arm architecture code
  • US companies contribute around 35-40%: significant, but not dominant

This is almost the opposite of Linux. A major infrastructure project where European companies have real influence and deep expertise. Funny how that works when you actually show up and do the work.

Detailed numbers are available here:

Xen Project 4.21 - Regional Contribution Analysis
💡
XCP-ng uses Linux, but in a specific, constrained role: handling hardware drivers inside a dedicated VM. The core isolation and security boundaries come from Xen, where there's direct expertise and influence. It's a deliberate architectural choice: keep the thing you don't fully control in a box, and make sure you do control the box.

I won't pretend the path Vates chose is the easiest. Mastering a stack costs real money and real time. We know it firsthand: we forked XenServer from Citrix, and it took years—years—to actually understand exactly what we were running. Add the upstream work on Xen itself, and it's definitely not the shortest route to market.

But it's the safest route to survival. And beyond our own company, it's creating something Europe desperately lacks: genuine expertise in low-level systems isolation. That knowledge stays here, no matter what happens anywhere else.

The real question

The goal here isn't to claim that Open Source doesn't matter for digital autonomy: it absolutely does. Access to source code is a prerequisite. But it's not sufficient.

The real question is:

Who masters the stack?

And "mastering" means:

  • Having engineers who deeply understand the code
  • Having influence over project direction
  • Having the financial capacity to maintain it independently if needed

Open source gives you the right to fork and maintain code yourself. But rights without capabilities are just words on paper. "You can fork it anytime!" sounds empowering until you realize you'd need to somehow replicate decades of institutional knowledge and millions in annual investment. Good luck with that.

A previous article was doing a deeper dive into the hypervisor part of the stack:

Who owns your virtualization stack?
In a world full of open-source wrappers and orchestration layers, who actually owns the foundation your infrastructure runs on?

A call to action (the optimistic part)

This isn't meant to be all doom and gloom. The situation can change, and there's a clear path forward.

If European companies invested more in critical Open Source development, everyone would benefit. More contributors means better code, faster bug fixes, more diverse perspectives on problems. The non-EU companies contributing today aren't losing anything by having European companies contribute alongside them. It's genuinely win-win.

But for Europe, increased contribution would mean something more: actual autonomy. The ability to maintain critical infrastructure regardless of geopolitical mood swings, trade disputes, or some executive in wherever deciding that Europe isn't a priority anymore.

So more than saying "Open Source isn't a guarantee of digital autonomy," this is a call for European companies to contribute more. Not just individual developers scratching their own itch on weekends, but organizations making strategic investments in the foundations everyone depends on.

The code is open. The question is whether Europe will step up to master it, or just keep assuming someone else will handle it.

Spoiler: someone else will. And they'll set the priorities.