Social Processes in Package Managers

All package managers download packages, install their recursive dependencies, unpack packages in the right directories, and record their location so they can be found by the language runtime. Some also go further, building C modules or documentation. Automating these technical steps is valuable.

But before using a package manager developers need to solve some social problems:

• Finding packages that do a particular task
• Figuring out which packages are actively maintained
• Choosing a package from multiple options
• Filing bugs in upstream packages and developing workarounds

Generally, develops solve these problems by asking friends, reading important blogs, or following a language's Reddit.

Many package managers try to help developers solve these social problems. Package servers allow package maintainers to name packages and put up descriptions. Some allow maintainers to categorize their package, so that similar packages are grouped together. Most enforce unique names (a form of trademark); almost all only give the maintainer permission to update the package. Some, like Perl's, automatically run tests and host documentation, helping with maintenance concerns.

These approaches help, but they restrict themselves to giving package maintainers ownership over the process. By requiring unique names and restricting package updates to the owner of the name, package managers hand responsibility for updates, compatibility, and maintenance to the owner of the name.

Having granted "ownership rights", the community must now choose the extent of these rights. Some package managers enforce semantic versioning, which weakens the rights of package maintainers to change the interface. Others allow substituting a later package version if one is available—handing power to the maintainer. But often the maintainer does not know what changes are breaking for which users. After all, the maintainer does not know how their library is used!

For example, consider a bug-fix release. It presumably changes behavior; should users update? Well, if the behavior change doesn't affect them, probably. If it does, is the change appreciated or not? It likely depends on the user.

I think it is best to take the perspective that at their root, different versions of a library are different libraries. Version numbers carry social, not technical, information.

What information do version numbers supply? Well, at least information about maintenance (older versions are not maintained) and bug fixes (bugs in old versions may be fixed in newer ones). When packages change their APIs significantly, versions also tell you which API is future-proof.

The package server could help users answer these questions, taking some of the burden off users. Package servers that are linked to version control systems could track commits, issues, and branches to know which packages are maintained. Dependencies from other packages can suggest which versions of a package are "stable". Bug-tracker-linked package managers could tell you what bugs were fixed between versions. When a package stops being maintained, the package server could also suggest other packages to transition to.

The package server could also take a more active role at upgrading packages between versions. A package server could keep track of how many packages upgraded their version of a certain dependency, and how many did it without code changes. It could then automatically upgrade other packages, rerun tests, and provisionally offer that version to others. Or non-maintainers could upload package versions, and library users could vote for which is "canonical". Perhaps package users could comment on upgrades?

Current debates about versioning treat it as a technical problem. It is a mechanism for solving certain social problems, and to fix versioning we may need to improve other aspects of the package ecosystem.