Analysis · ·

Can Europe Build a Sovereign Stack on Open Source?

Open source is essential to Europe’s sovereignty debate, but it is not a magic word. Who governs, maintains and secures the stack?

A stack of white slabs resting on a foundation of small amber bricks, one missing

Illustration by the author.

This is one of the questions I keep coming back to while following the debate on European technological sovereignty, and it deserves a calm, practical answer rather than an ideological one. Can Europe build a truly sovereign technology stack by relying on community-driven open source?

For those of us who have spent years in the technology sector, open source is not a slogan. We have watched Linux evolve from a niche curiosity into the backbone of the modern internet. We see Apache, PostgreSQL, Kubernetes, Python, Git and OpenSSL acting as the invisible infrastructure of daily life. But we have also seen the flip side: forks that quietly die, foundations that struggle to survive, maintainers burning out under unpaid pressure, vendors abruptly shifting licences to proprietary models, and the word “community” degraded into a cheap buzzword for marketing decks.

The vision of a united digital future ultimately rests on developing sovereign technology that meets the needs of all Europeans, and open source matters deeply to it: it is one of the strongest tools Europe has to reduce dependency, increase transparency and build reusable digital public infrastructure. A hard question nonetheless underpins the current debate. Can every critical layer of a European technology stack genuinely be built on solutions that are fully open source, mature, secure and driven by a truly independent community?

The two faces of the stack

In certain domains the answer is a clear and resounding yes. Operating systems, containers and automation, observability platforms, developer platforms and the whole cloud-native ecosystem: here open source is no longer an experiment but industrial infrastructure. In other areas the reality is far more complicated. Cloud infrastructure and semiconductors, GPUs and AI models, training datasets and security supply chains, quantum technologies and critical operational platforms are fields where “open” is rarely binary.

Sometimes a technology becomes the hyper-stable, pervasive backbone of public administration, only for its licensing terms to be retrofitted or restricted overnight by the single commercial entity that controls it. Sometimes a project is led by a single supplier, yet the code becomes stable, widely adopted and genuinely useful to communities and enterprises alike. That should not be dismissed: strong stewardship can help technologies mature faster, harden in production and reach a level of operational quality that purely volunteer-driven projects may struggle to sustain.

The question is not whether a supplier is involved. The question is whether users retain practical control: roadmap transparency, deployment choice, portability, security processes, operational knowledge and credible exit paths. Sometimes model weights are public but the training data remains opaque. In other cases the expertise required to run critical engines at scale is concentrated in very few hands. This is why “open” should not be treated as a label but as a spectrum of practical control, and it is exactly where Europe needs a more mature conversation.

Moving beyond the licence

The question should not be whether we can publish the perfect European open-source stack. The better question is what makes a technology component sovereign enough for critical European use. Answering it means looking far beyond the licence file and asking hard, operational questions. Who controls the roadmap? Who maintains the project when the initial enthusiasm fades? Who fixes vulnerabilities at 2 a.m.? Can public administrations contribute upstream, or are they stuck maintaining isolated, dying forks? Can multiple European providers actually operate and support it? Is there real portability, or just a beautiful architecture diagram?

This is the dimension we routinely underestimate. A public administration does not simply adopt code; it adopts risk. It inherits a supply chain and a dependency map that may last for decades. Technological sovereignty cannot be reduced to a binary of open source good, proprietary bad. Reality is far more demanding.

Two traps to avoid

As Europe navigates this path it must avoid two distinct pitfalls. The first is open source romanticism: the naive belief that community software automatically yields sovereignty. It does not. Without funding, dedicated stewardship, rigorous security engineering and long-term maintenance, even the best open-source software becomes fragile infrastructure.

The second is sovereignty-washing: replacing a foreign monolithic dependency with another foreign dependency and calling it independent simply because a local vendor has stamped its label on it. That does not create sovereignty; it merely relocates the lock-in.

Why it matters

Europe should aim higher. The goal must be a qualified, dynamic technology framework built on community-led open source, one where mature open standards, transparent governance and shared investment in the digital commons meet ruthless security and operational responsibility.

Sovereignty is not just the right to see the code. It is the practical capacity to understand it, run it, secure it, maintain it, replace it and evolve it under pressure. Open source is essential to that story, but it is not a magic word. It is a discipline.

Newsletter

Get the next essay before it goes out anywhere else.

New essays and each new field guide, by email. Free, no ads, one-click unsubscribe.

Field guides only? Choose your list.

More in Technology Culture

Suggested Reading