What governments and funders could do

The gap between these columns is where standardization would reduce switching costs. Not building a European deps.dev, but defining a common dependency graph API. Not building a European Dependabot, but standardizing how dependency updates get proposed. A protocol for package management could let different implementations compete on the same interfaces. GitHub and GitLab bundle dependency features into their platforms: dependency graphs, vulnerability alerts, automated updates. A self-hosted Forgejo or Gitea instance doesn’t have equivalent tooling. But if those features were built on open standards and open data sources, switching forges wouldn’t mean losing supply chain visibility. The dependency intelligence could come from any provider that implements the same interfaces, rather than being locked to the forge vendor. Some gaps need new standards rather than adoption of existing ones. There’s no good specification for package version history across registries. Codemeta describes a package at a point in time, not its release history. PkgFed proposes using ActivityPub to federate release announcements, similar to how ForgeFed handles forge events.

The package registries follow a similar pattern, with a few European exceptions: Registry Owner Country npm Microsoft US PyPI Python Software Foundation US RubyGems Ruby Central US Maven Central Sonatype US NuGet Microsoft US Crates.io Rust Foundation US Go module proxy Google US Docker Hub Docker Inc US Conda/Anaconda Anaconda Inc US CocoaPods CocoaPods US Pub.dev Google US CPAN Perl Foundation US Homebrew Homebrew US Hex.pm Six Colors AB Sweden Packagist Private Packagist Netherlands CRAN R Foundation Austria Clojars Clojars Germany

The same logic applies to the software supply chain, though that layer gets less attention in sovereignty discussions than cloud and storage.

I’m Andrew Nesbitt. I’ve spent the last decade thinking about package management.