The message from the stage in Prague
One of the strongest themes I encountered at Open Source Summit Europe 2026, held in Prague on 7–9 October, was that European digital sovereignty is not solved by buying a different cloud. It requires control over the software, governance, dependencies, and communities underpinning your infrastructure.
My photographs from the opening keynote block include the 2026 State of Open Source in Europe research launch and a slide advancing a simple argument: open source offers a path to choice, transparency, and shared stewardship instead of trading one dependency for another.
The research launched in Prague on October 7 gives that argument some concrete numbers. The Linux Foundation Europe’s announcement and the full 2026 research page are worth reading together.
94% say sovereignty matters — but strategy and execution are different
The Linux Foundation reported the following findings from surveyed European organizations:
| Finding | Reported result | Why it matters |
|---|---|---|
| Digital sovereignty is important to technology strategy | 94% | Sovereignty has become a mainstream strategic objective |
| Digital sovereignty is very important | 61% | For many respondents it is a high-priority decision criterion |
| No formal open source governance framework | 31% | An adoption-to-governance gap remains |
| Maintain private forks of open source projects | 48% | Organizations can inadvertently create new maintenance liabilities |
| Increased investment in open source dependency management owing to regulatory pressure | 63% | Supply-chain visibility is becoming an operational requirement |
These are survey findings, not a census of all European organizations. They are useful for spotting priorities and gaps, not proof that every organization has reached the same maturity.
The most interesting tension is that almost everyone says sovereignty matters, yet nearly a third of respondents report no formal open source governance framework. Using Linux or Kubernetes is not the same thing as controlling the systems built on them.
Sovereignty means exit options you can actually exercise
The cloud sovereignty discussion at Open Source Summit Europe 2026 in Prague. Photo: Luca Berton.
Consider two platforms.
Platform A deploys Kubernetes on a single vendor’s managed stack. Its cluster objects are nominally portable, but identity, observability, data pipelines, build processes, and application delivery all depend on proprietary services. If the provider changes prices, regions, or terms, leaving may take years.
Platform B documents open interfaces, keeps infrastructure definitions in version control, rehearses restore procedures, owns its signing keys and artifact registry strategy, and tests whether critical services can be migrated.
Both may use open source. Only the second has actively engineered for choice.
A practical sovereignty assessment asks:
- Can we export data and configuration in usable, documented formats?
- Can we rebuild the service without a single supplier’s control plane?
- Who can patch and rebuild our dependencies if the original provider disappears?
- Are the critical projects openly governed, with sustainable maintainers?
- Can we verify software origin, licenses, signatures, and security posture?
- Have we tested an exit plan rather than merely written one?
Data residency and jurisdiction still matter, but they are only part of this engineering picture.
The hidden price of private forks
One of the report’s most practical findings is about forks. The Linux Foundation says organizations maintaining private forks spend an average of 311 hours per release cycle patching 9.5 forks, while 28% say they cannot track the costs at all.
A private fork can be justified: an urgent patch, a required feature, or support for a legacy environment. But long-lived forks become an invisible form of lock-in.
Upstream open source project
|
+----> Contribute fix upstream (shared maintenance)
|
+----> Private fork (local patching obligation)
|
+--> Rebase
+--> Security testing
+--> Build and release
+--> Compatibility testing
+--> Incident ownershipThe answer is not “never fork.” It is to assign every fork an owner, an upstream contribution plan, a supported version, a patch SLA, and an exit condition. If the organization cannot explain why a fork still exists, it probably needs to be retired or upstreamed.
Open governance has economic value, too
The same research associates more mature open source governance with a higher reported benefit-to-cost return:
- 4.6× for organizations with advanced governance.
- 3.6× for organizations without formal governance.
Those figures describe an association in the report, not a causal guarantee that establishing an OSPO will immediately improve ROI.
The plausible mechanisms are nevertheless concrete: fewer duplicated patches, clearer dependency ownership, consistent licensing reviews, better component reuse, and an easier path for developers to contribute upstream.
At the platform level, governance should not become a ticketing bureaucracy. It works best as a set of developer-friendly defaults:
- Approved base images, provenance checks, and dependency-update automation.
- Golden paths for deploying and operating services.
- A searchable inventory of critical open source dependencies and maintainers.
- Simple guidelines for upstream contributions and legal review.
- An explicit process for handling exceptions and end-of-life components.
That is platform engineering as a sovereignty enabler.
From consumers to contributors
The Linux Foundation also highlighted that European developers account for nearly 40% of contributions to selected foundational infrastructure projects, including Kubernetes and OpenStack. The precise scope of that figure matters: it is not a claim about 40% of every open source project worldwide.
The strategic lesson is participation. If an enterprise depends on an upstream project, it has choices beyond paying for support: contributing fixes, testing releases, funding maintainers, reviewing designs, joining governance, and sharing production feedback.
That participation is what makes vendor neutrality sustainable rather than purely contractual.
My enterprise checklist after Prague
For engineering and technology leaders, I would start with a 90-day exercise:
Days 1–30: Map dependencies. Identify critical services, software bills of materials, the projects they depend on, operators, cloud-specific integrations, and private forks. Name accountable maintainers internally.
Days 31–60: Test recoverability. Rebuild one representative workload in a secondary environment. Test database restore, identity integration, artifact retrieval, and network policies. Record the undocumented dependencies you discover.
Days 61–90: Reduce lock-in. Choose the three largest blockers. Upstream a maintained patch where possible, document export paths, automate provenance checks, and create a funded support plan for high-risk community dependencies.
None of this requires abandoning commercial suppliers. It requires being able to choose, challenge, and replace them.
Final takeaway
The story from Prague is bigger than “Europe wants sovereign clouds.” The 2026 State of Open Source in Europe research suggests that Europe’s ambition is substantial, but governance, fork maintenance, and supply-chain visibility have not caught up everywhere.
Open source creates the possibility of sovereignty. Good engineering and participation turn that possibility into an operating capability.
For my general conference coverage, see Open Source Summit Europe 2026 in Prague. For the infrastructure perspective, read Digital Sovereignty: Governance and Trust Architecture and EU Digital Sovereignty and Cloud Strategy.
Sources: Linux Foundation Europe, 2026 report announcement · 2026 State of Open Source in Europe · Official summit schedule
