1 Matching Annotations
  1. Last 7 days
    1. 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.

      This points to where standards can reduce friction. a common dependency graph API standard for proposing dependency update protocol for package management dependency features based on open standards / open data so that dependency intelligence is not a lock-in element.

      New standards need for package version history across registries. Mentions PkgFed en Forgefed vgl [[PkgFed ActivityPub for Package Releases]]