GitHub announced that they are releasing a package registry called GitHub Package Registry.
Funny timing. For the past two weeks, while thinking through how to create the right UX to improve the sustainability of open source software, I began wondering whether there should be a neutral and sustainable package manager, perhaps housed in an institution like the Linux Foundation.
The GitHub Package Registry is different from what I was thinking, but had it appears to be the smarter and more logical conclusion if I were to have kept walking down this path of exploration.
What does a package registry do?
A package registry holds the "package" that one would want to install and run on their system. Some registries also come win a package manager, a client that one installs, which allows someone from the CLI to search for and find packages.
The difference between what GitHub has been traditionally known for and this new product is that repositories held the source code. Developers who wanted to read code or fork it themselves could do so.
But some code still needed to be packaged or "built." An example of this would be when using "apt-get" to update or install new capabilities on your Linux OS.
The source code alone wasn't sufficient. If you watched the terminal after running the command, you could see that lots of dependency checking or even removing of old code a files would appear to happen "automagically."
Ian Murdock asked in a blog post, "What’s the single biggest advancement Linux has brought to the industry?"
Here is his answer:
It’s an interesting question, and one that in my opinion has a very simple answer: Package management—or, more specifically, the ability to install and upgrade software over the network in a seamlessly integrated fashion—along with the distributed development model package management enabled
The writer put together more succinctly what I was thinking about.
The combination of a registry with the source code packaged and a easy-to-use CLI interface for the package manager accelerates the discovery and adoption of code.
Since I was exploring how to get more developers -- those writing code and those installing code -- to participate in a platform that would increase the sustainability of all open source software, I was drawn to that interface.
Packager managers live where developers live
The registry, which is a valuable utility for both builders and users, looks like a great vehicle for go-to-market of a broader platform.
For example, the package manager outputs text which can provide useful links. If the package repository also did vulnerability scan, that information could be output to the terminal, with links to encourage developers to put their own code on the platform to help secure it.
The terminal could output information suggesting how the user could influence the roadmap or accelerate critical feature development through a streamlined funding mechanism.
Because the package manager lives where developers live (as do repos like GitHub) because of its UX and utility, it also has potential to create more value by broadening adoption of related and relevant adjacent services like security.
Are there risks with current package managers?
Since open source software is the Internet, when something goes awry, as it did with npm, you get headlines like the following:
- How one programmer broke the internet by deleting a tiny piece of code
- Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”
- How a Programmer Nearly Broke The Internet by Deleting Just 11 Lines of Code
The risk isn't with the software itself. It's with governance. What happens when, as in this case, npm mandates that an open source developer change the name of his project. What happens when the developer un-publishes a package that many widely-used frameworks depend upon (and breaks dependent-code during build when unpublished). Is un-unpublishing the right move, as npm did, in terms of its relationship with the developer?
No answers here, but it made me think about how critical package managers are because they are that common, centralized gateway.
What would happen if a package manager, such as homebrew, were compromised?
This blog post1 describes how a potential attacker could exploit homebrew's recommended chmod and PATH configurations to compromise user passwords and more.
GitHub now has both source code and packages
According to the GitHub blog post2, GitHub Repository Manager is just a repository. It will work with existing package managers like npm and RubyGems. So it doesn't need to compete with existing package managers, or is there a reason to.
If they were to support homebrew, for example, that is a win for everyone.
GitHub is becoming the center of open source development. By being the networked utility that developers use, they are the platform. Adjacent products in the developer ecosystem will not only need to integrate, as many already do, but may find it as a primary vehicle for their go-to-market.
I want to noodle on that more and write as part of another post.
Questions:
- Would a neutral party be a better repository, perhaps even package manager, in terms of governance?
- Do those package managers being run by unpaid volunteers create a risk?
- What is the end-game of Microsoft making such a meaningful investment in the product mean, given the history of stagnation to date?