eu-feedback.txt

The Commission's call for evidence rightly identifies European reliance on non-EU digital technologies, but focuses primarily on cloud infrastructure, AI, and end-user applications. There's a critical layer missing: the dependency intelligence infrastructure that sits between source code hosting and application deployment.

Open source software underpins 70-90% of all code in the digital economy. But the infrastructure that tracks, analyses, and secures that software is almost entirely US-controlled: package registries, vulnerability databases, dependency graphs, software composition analysis tools, and automated update services. A European company can self-host Forgejo for code hosting and still depend entirely on US services for vulnerability scanning, dependency updates, license compliance, and SBOM generation.

The M×N Problem

Package management has an M×N problem. Every tool implements support for every ecosystem separately. When a new language ships a package manager, it goes to the back of every queue. No Dependabot support, no advisory database coverage, no PURL type for SBOMs. This is structural.

Before the Language Server Protocol, every IDE implemented support for every language: M×N integrations. LSP changed that to M+N. Package management needs the same thing.

The lack of a protocol creates lock-in by default. Not malicious, just gravitational. A protocol would make the dependency layer contestable. Run your own registry that federates with others. Stand up a regional vulnerability database that speaks the same language.

Where Standards Exist and Where They Don't

Some de facto standards have emerged. Git is universal. Semver is dominant. Some areas have formal specs: PURL for package references, OSV for advisories, CycloneDX and SPDX for SBOMs, SLSA for provenance.

Other areas don't. Dependency graph APIs vary by platform. Vulnerability scanning integration is proprietary per forge. Dependabot and Renovate have their own config formats. Package metadata APIs differ across registries. Most standards work focuses on compliance artifacts. Less attention goes to the underlying tools developers actually use.

The gap is where standardisation would reduce switching costs. Not building a European deps.dev, but defining a common dependency graph API. Not building a European Dependabot, but standardising how dependency updates get proposed.

Concrete Measures

First, treat dependency intelligence as infrastructure worth funding directly. The Sovereign Tech Fund model applies: direct funding to open source projects that serve as foundations. Ecosyste.ms, VulnerableCode, OSV, PURL implementations, CycloneDX tooling, Forgejo's dependency features.

Second, fund protocol development. Someone needs to define common interfaces for dependency graphs, package metadata, vulnerability feeds, and update notifications.

Third, use procurement to drive adoption. If an agency requires SBOMs, require that generation doesn't depend on proprietary services. Government procurement moves markets.

Fourth, coordinate procurement language across member states. Shared interoperability requirements would move the market.

The Cyber Resilience Act will require SBOMs and vulnerability handling. If that infrastructure remains US-controlled, European compliance with European regulations will depend on American services. The Commission has an opportunity to shape this market while it's still forming.

Further reading:
https://nesbitt.io/2026/01/28/the-dependency-layer-in-digital-sovereignty.html
https://nesbitt.io/2026/01/29/zig-and-the-mxn-supply-chain-problem.html
https://nesbitt.io/2026/01/22/a-protocol-for-package-management.html
https://nesbitt.io/2025/12/21/federated-package-management-and-the-zooko-triangle.html

Andrew Nesbitt, founder of Ecosyste.ms (11M packages, 22B dependencies tracked). Co-organizer, FOSDEM Package Management devroom and CHAOSS Package Metadata Working Group.