Suddenly, Linux needs a universal package manager for installing software. At least, that's what Canonical Software claimed when it introduced its new Snappy packages. However, if the need is there, which package manager should be adapted?

Mind you, the necessity is far from obvious. Canonical has been using the Debian package manager for over a decade, apparently without major difficulties. Moreover, Debian maintainers insist that the solution to any problem is a well-defined package format, like the Debian Policy Manual.

In fact, considering that Flatpak, Fedora and Red Hat's candidate for a universal package manager, was rushed out a few days after Snappy was announced, it appears that the issue is not necessity so much as a corporate rivalry that is being played out in the Linux community -- the last place that it belongs.

Still, accepting the claims about universal package managers at face value, which one would benefit Linux the most? Some choice must surely be made, or the main result of trying to implement a universal package manager, as many point out, would be to replace the longtime rivalry between Debian and RPM packages with yet another conflict between competing standards, which would remove one of the main rationalizations for raising the issue.

Universal Package Manager: Technically Speaking

The best universal package manager selection is unlikely to be made based on technical reasons alone. Even a quick glance at the four main candidates -- AppImage, Flatpak, Snappy, and GNU Guix -- shows that they all share similar features for installing, deleting, updating, or rolling back packages or for viewing packages or a list of installed packages.

Each has features that the others do not; for example, Snappy has delta updates that install only the code that is new since the last update, while Guix can use already installed dependencies, or else download and build dependencies as needed. However, there seems to be no reason any of the four candidates couldn't be modified to include any of the features that the others have.

Similarly, all the candidates isolate packages for enhanced security, but similar security could be had using Firejail to run the application or by installing in containers if they do not already do so.

The manual pages and project wikis tell the story: none of the candidates have such a strong technical advantage that they become the obvious choice. Moreover, all are still in a development stage in which missing features can easily be added.

The Political Choices

In this situation, the question quickly becomes: who do you want to control such a basic feature as software installation in Linux?

Canonical, I suggest, has already forfeited such a level of trust. It has a regular history of starting projects like Mir, Unity, and Upstart in-house, and requiring outside contributors to assign to Canonical all rights in their code, including the right to change software licenses.

All these habits can be illustrated in the development of Snappy for Ubuntu, which was only ported to other distributions a couple of weeks after the initial announcement. In a phrase, Canonical has never played well with others, and shows no signs of mending its ways.

Although a much larger corporation than Canonical, Red Hat would be a better choice because it has been a better friend to open source. Admittedly, Red Hat has had its own share of projects that were initially developed in-house, and mostly by employees, but Red Hat has also contributed to community projects that gave it no immediate return. To a far greater extent than Canonical, it appears to understand the need for the main aspects of Linux to be controlled by the community.

However, why should a universal package manager be dominated by any corporation? If nothing else, some Linux developers dislike dealing with corporations. Just as the Linux kernel was kept independent by having the Linux Foundation fund key developers, so package management should be kept independent of direct corporate influence as well.

By this logic, the choice should be either be AppImage or Guix. However, of the two, Guix is preferable because, as part of The GNU Project, it has strong ties to the Free Software Foundation, and demonstrates a strong commitment on its site to the principles of free software. By contrast, AppImage is unaligned and, with its BSD license, less committed to free software. If a universal package management must be implemented, I hope it will be with Guix and under community control, which is where it belongs.

Community Co-operation Vs. Corporate Dominance

Corporations are welcome in open source when they abide by community standards. However, when they take their rivalry into the community, that is another matter. However important a universal package manager might be to the goals of Canonical and Red Hat, incremental improvements in package managers that have served reasonably well for years seems a more useful approach for the community. In the community, lining up behind two corporate choices is only a distraction.

Nor is observing this distinction only a matter of ideology. Open source is built on the idea that, in certain circumstances, co-operation is more efficient than competition. However, by offering competing standards in the core parts of Linux, Canonical and Red Hat are undermining the ideas that make open source worth participating in. Even if dominating a key aspect of Linux seems beneficial to a corporation in the short run, in the long run, the most beneficial course for everyone is to keep corporate rivalries out of the community.