Distributions offer convenient tools for retrieving programs and other software components. Package managers such as Apt or Yum let you search for, download, and install software in the form of packages.

Classic formats for packages provide one package per piece of software; the package then contains the desired software and some metadata. The latter includes information, such as the name, version, and author of the software, as well as other software dependencies. The package manager parses the metadata and carefully resolves all the dependencies so that installing a package can trigger a number of additional downloads and installations.

As a result, you achieve a state in which the desired program is executable from disk, thanks to meeting the dependencies. Don't forget that installing other software with the same dependencies is far faster now because the required packages are already available. This means that several packages can use the same components (e.g., OpenSSL).

These typical package management systems, however, are specific to a distribution and suffer from various weaknesses (discussed in the next section). For more than a decade, now, developers have looked at the basic principle of a cross-distribution run-time environment for programs and have designed various modern formats that solve some of the problems. Once packaged, the applications run wherever the appropriate environment is available – whether under openSUSE, Ubuntu, or Fedora.

These modern approaches come from different communities or companies and have therefore not necessarily developed in the same direction. To find out which formats might prevail in the future and which are recommended, it is worth taking a look at the three best-known representatives of the genre: Flatpak, Snap, and AppImage.

Old-Timers

The concept of modularity created by RPM, DEB, and other package formats contributed to the triumphant advance of Linux: In most cases, you did not have to search the Internet for a software source (e.g., as for Windows) and check its trustworthiness.

However, the major share of today's widespread formats originated in the mid-1990s, when the demands on workstations and servers were far different from today. It is thus unsurprising that the basic ideas behind these formats have some disadvantages from today's perspective.

By definition, most classic package formats do not let you install different versions of the same software and switch between them, although you can find isolated (thoroughly successful) approaches within the classical mechanisms that are intended to remedy this situation. However, these solutions add additional functions that are not anchored to the format of the packages themselves and therefore require more administration.

The same applies when resolving dependencies. If, say, two web applications on a server require different PHP versions, you will probably experience a conflict during installation. This then forces a decision: Is it worth outsourcing one of the applications or even manually adapting and, if necessary, rebuilding the packages to resolve the dependencies cleanly? Neither approach sounds very tempting, and both require additional time. This is especially true when updates reach the package sources.

The handling of new versions is often a bit inconvenient: If a new version of an installed package is available, the package manager downloads the entire archive once again. Some formats cut this, often unnecessary, overhead by only downloading the delta of the two versions. However, this approach is not widely used and is by no means standard in all distributions.

Especially if you need to manage larger environments, the fact that the classic packages offer hardly any interfaces for external communication has a negative effect. In practice, for systems such as Puppet or Ansible, this means that a package first stores the maintainer's configuration during the install. Afterward, you need to overwrite or at least adapt this so that the updated application runs with the desired parameters.

From a user's point of view, as well as from the software manufacturers' perspective, the classic formats are a bit of a nuisance. Vendors need to build and maintain their software for many different distributions. If you want to support many platforms, you can build for Debian, Ubuntu, CentOS, Red Hat, Fedora, openSUSE, Arch Linux – the list is endless.

In some cases, community maintainers do this work; in other cases, this build process is automated across the distributions' boundaries. Nevertheless, the packager must think of all possible dependencies and peculiarities of the different platforms. Software installation is basically reserved for users with corresponding privileges.

Inventive

There is no shortage of creative ideas to correct the disadvantages of classical package management: Docker container automation [1], for example, follows the principle of a single image of a container including all libraries and other dependencies for the application running in it. The container can therefore be run wherever Docker is installed. However, many users are put off by the complexity of Docker and the effort involved in familiarizing themselves with it, so they prefer not to take advantage of the technology. However, there is a solution one size smaller.

Youngsters

The introduction of the DEB [2] and RPM [3] package formats coincided with the birth of the major distributions Debian and Red Hat. In contrast, the modern Flatpak [4], in particular, appears extremely youthful. Work on the project began in 2007, when Swedish developer Alexander Larsson – at that time still using the bundle format Glick [5] – looked to emulate furniture manufacturer Ikea when it came to packaging. A few years later, the mature xdg-app format emerged; it was finally renamed Flatpak in June 2016 [6]. Larsson himself works for Red Hat and the Fedora project; his development work thus draws on many components that were originally developed at Red Hat.

Snap [7], on the other hand, was written by Ubuntu manufacturer Canonical. It is a further development of the .click package format, which was used on the Ubuntu Phone in 2013. In the following year, the company continued the principle of apps under the name Snappy on the Internet of Things (IoT) platform Ubuntu Core, until Snap finally made its way onto the desktop version of the system with Ubuntu 16.04. In June 2016, Canonical decided to open the format for other distributions and purposes.

AppImage's history goes back to 2004, when developer Simon Peter developed klik. At that time, users could use the browser and special URLs beginning with klik:// to obtain recipes that generated a local executable file for the program. This gave Peter a certain degree of independence from platforms because the system did not deliver the executables from the beginning. New versions of klik never exceeded beta status, which is why Simon Peter released PortableLinuxApps in 2011, a successor that works differently. The project matured and was given the new name AppImage in 2013.

Table 1 compares some of the properties of Flatpak, Snap, and AppImage.