GitHub has the opportunity to streamline and secure the package management layer. Here's how.

GitHub is the system of record for code. But the company rarely takes advantage of this. GitLab, on the other hand, has used this fact to build out products that span the entire software development lifecycle. But GitHub's strength is the sheer amount of public projects it has – projects that end users consume mostly through package managers.

How does it work today? When a developer updates a package they follow roughly these steps:

  1. Make some code changes and push to Github
  2. Tag that revision with in git (e.g., v1.0.1) on GitHub
  3. Publish a release on GitHub
  4. Use that same tag and bundle the code into a zip file
  5. Publish to a package manager (e.g. npm for JavaScript/TypeScript)

Not only does the package manager have three pieces of redundant information (code, version, and package name), there's no guarantee that these correspond to the open source code on GitHub. Here's a quick list of a few things that go wrong in this process.

GitHub can fix all of these issues simply by maintaining its own package registries that conform to each language's requirements (i.e., npm endpoint for JavaScript, pip for Python). Packages would correspond 1 to 1 with published releases.

Users could either configure their existing tools to point to GitHub's endpoints or GitHub could publish its own tool that covers the most popular languages.

Why would GitHub do this?