Context
On 3 June 2026, the EU Commission published the Open Source Strategy as part of COM(2026) 503 final, the Communication on European Tech Sovereignty. It came together with two legislative proposals: the Cloud and AI Development Act (CADA) and the Chips Act 2.0. The strategy is aspirational. CADA and the Chips Act 2.0 are the legislation. That distinction runs through the whole analysis.
This post is a summary. I identified ten strengths and eleven weaknesses in the three original articles published on Tagoross Community of Practice. Here I summarise only a few of them. The rest are listed in one sentence each.
What the Commission got right
Two of the strengths deserve a longer note.
Open source as a strategic lever, not a procurement preference. For the first time, the Commission treats open source as central to EU sovereignty policy. Not as a side issue. Not as a buying option. Section 4 of the Communication links it explicitly to cybersecurity, resilience, interoperability, and the reduction of vendor lock-in. This is a real shift in framing. It changes the conversation we can have with public administrations and with industry, regardless of how well the execution lands.
CADA Level 2 supply chain transparency. Level 2 of the CADA four-level sovereignty framework requires a complete and up-to-date SBOM and controls over the open source components used in the service. In practice, that creates a structural procurement advantage for organisations already investing in SBOM, open source provenance, and CRA-aligned compliance work. It is a concrete, downstream-visible measure that translates strategy into market behaviour.
The other strengths, in one sentence each:
- The Commission recognises open source communities as strategic actors, not as a free input to be consumed.
- The Open Source Maintenance Instrument proposes dedicated funding for the security and maintenance of critical dependencies.
- The Digital Commons EDIC is a federated instrument that already exists and can own assets and sign contracts.
- The Next Generation Internet (NGI) precedent funded over 1,700 grassroots projects through Horizon 2020 and Horizon Europe.
- The strategy proposes to integrate open source communities into EU standardisation work.
- Annex I and Annex II together move the strategy from principles to real implementation machinery.
- Section 4.3 documents genuine internal open source activity at the Commission, with code.europa.eu, Matrix, openDesk, and the open source labs.
- The public sector is positioned as an anchor customer for open source solutions.
The design flaws and what the legislation does not back
Four of the EU Open Source Strategy weaknesses deserve a longer note.
The sovereignty definition does not fit open source. The strategy defines technological sovereignty as Europe’s ability to develop, control and scale critical technologies. The first three requirements of that definition are about control. Sovereignty in open source is not earned through control. It is earned through influence. That mismatch shapes everything downstream: what gets funded, what gets measured, what gets reported. A wrong definition produces a correctly executed wrong strategy.
The strategy prescribes rather than demonstrates. The Commission writes as a regulator telling the market what to build, adopt, and procure. It underuses its own position as a large software consumer and operator at scale. Demonstration creates demand. Prescription creates compliance costs. The Commission’s most powerful and most underused lever is its own conduct as a buyer and operator. If EU institutions adopted community-governed open source as their default, that would move the market. Guidance for public administrations will not, or will do it too slowly to reach the stated goals in time.
Open source is not a business model. Section 4.2 of the Communication is titled “Strengthening and promoting a vibrant open source ecosystem”. Its first sub-heading is “Scaling up open source startups and open source business models”. Open source is not a business model. It is a collaboration and production framework with a strong cultural component around the concept of the commons. People and organisations build different business models on top of it. By treating open source as a business model, the strategy misses individual contributors, universities, non-profits, and upstream contributors who do not sell software or services. Those are the people who maintain many of the dependencies the strategy wants to secure.
The legislation does not carry the strategy’s ambitions. CADA and the Chips Act 2.0 are the two legislative instruments in the Sovereignty package. Chapter V of CADA on open source uses the verb “encourage” and opens the door to any exception a public body can justify. That is not “Open Source First”. It is open source as one option among others. The Chips Act 2.0 proposal, COM(2026) 504 final, does not contain the phrase “open source” at all. “Open foundry” in Article 19 refers to manufacturing access, not open source. Where the legislation is weak on open source, or silent on it, the strategy’s ambitions have no legal force to back them.
The other weaknesses, in one sentence each:
- “Public money, public code” appears in the strategy as a principle without instruments to enforce it.
- The investment logic is centralised, in a market that Section 4 itself describes as dominated by small firms.
- The strategy does not build on the NGI model documented in its own Annex II.
- The Annex I KPIs measure activity and spending, not influence or governance weight.
- The diagnosis mixes production with influence, when Europe does not actually have an open source creation problem.
- The productisation problem is misread as regulatory friction, when it is a productisation and service-building problem.
- Community-driven and vendor-driven governance models are treated as equivalent for sovereignty purposes.
I asked NotebookLLM to create an infographics summarising the arguments of the articles published at Tagoross.
Summary
The EU Open Source Strategy is a modest step forward, in my opinion. It elevates open source from a procurement question to a sovereignty instrument. It also contains real design flaws: a sovereignty definition that does not fit open source, KPIs that measure activity rather than influence, and legislation that encourages or stays silent rather than requires, to name a few. It is 2026. I expected way more and especially better from the EU Commission.
I would like to read your assessment. What do you miss? What do you think it is worth supporting?
toscalix 