From control to capacity to govern: addressing open source's own weaknesses

One of six themes that emerged from the EOLE 2026 online kick-off workshop (25 June). Background: see the kick-off topic.

Why it matters for sovereignty. Much of the sovereignty discussion is not about control but about the capacity to govern: the ability to manage, adapt, audit and run your digital infrastructure, the way GDPR and the AI Act frame it for data and AI systems. Open source increases that capacity, but only if its own weaknesses are addressed.

What came up at the workshop. Two sides of the same coin. On one side, what open source brings: licensing rights, independence, the ability to audit and decide. On the other, if openness is to be a structural element of digital sovereignty (personal, regional, national, EU), then sustainability, underfunding, vulnerabilities and uneven maturity must be tackled with explicit mitigating measures, the gap that proprietary contracts usually paper over. This is also the direction of the EU’s emerging sovereignty strategy. And it loops back to the definition debate: because “open source” means different things (licensing, sustainability, governance, security), each element must be addressed on its own terms. One sharp formulation from the board: there is no way to say whether an IT infrastructure and its software are “sovereign” without a universally recognised, trustworthy checklist to procure and audit systems, software plus infrastructure. Related board items: the meaning of “structural sovereignty”, attaching a strategic value to projects regardless of headcount, Open Source Steward institutionalisation, the EU Stack, data sovereignty in practice, cloud supply chains.

What already exists to build on. SBOM tooling and compliance automation; CHAOSS metrics to understand the communities behind projects; the Sovereign Tech Fund; governance analogies from GDPR and the AI Act; the EU’s emerging sovereignty / open source strategy.

Open questions. Which concrete mitigating measures de-risk open source as infrastructure (security, maintenance, funding)? Can “structural sovereignty” be defined usefully? Can we draft a trustworthy checklist for procuring and auditing “sovereign” systems? How to score the strategic value of fundamental but forgotten projects?

How to contribute. Reply below with metrics, checklists, frameworks and cases, ideally by end of September 2026. Rapporteurs welcome for the Barcelona event (November 2026): volunteer by replying below or by direct message on this forum. Possible outputs: a “capacity to govern” framing note and a draft sovereignty audit checklist.