This year was a big one for companies like Canonical and Slack. It also was a big year for technologies that Canonical created to enable third-party application support—specifically, the snap package.

I'm sure most, if not all, of you have heard about this package manager. In fact, it's been around since at least 2014, but it initially was developed around Canonical's Ubuntu phone operating system. Now, although the phone operating system has since been canceled, snaps continue to dominate the operating system, in both the server and desktop space.

A "snap" application package is a self-contained piece of software, and although it originally was designed to be hosted on Ubuntu, the package will work across a range of other Linux distributions. This isn't your traditional APT or YUM manager hosting DEB and RPM (or other) package formats.

Again, the appeal to snap packages is that they are self-contained (that is, containerized). They are designed to auto-update and are safe to run. A snap package is bundled with its dependencies, which is what allows it to run on all other major Linux distribution without any modification. It also doesn't have any dependency to any package manager or application store. But, don't misunderstand this—a package manager or application store still can host one or more snap packages; however, the snap package is not dependent to that manager.

Snapcraft is the official tool for software developers to package their software programs in a Snap format.

Earlier this year on January 18th, Canonical announced the first iteration of Slack as a snap. But, why was this announcement so important? I recently had the pleasure of sitting down with Evan Dandrea of Canonical and Felix Riesberg of Slack. They gave me the answers I was looking for.

Evan's team at Canonical builds the platform to make everyone's life easier—that is, Snapcraft. And Felix's team leverages that very same platform to bring wonderful applications, such as Slack, to your Linux desktop.

First, for those not familiar with Slack, it's an enterprise software platform that allows teams and businesses (of all sizes) to communicate effectively. It's organized, easily accessible, and more important, it allows for better and more efficient communication than email. Slack isn't limited to just professional use; it also can be adopted for more personal uses.

Petros Koutoupis: Why snap?

Evan Dandrea: Traditional packaging works well—to a point. You are looking at a collection of software carefully curated by a team of engineers and coming straight from source. Also, one update affects many updates. The package has to be open source, and the traditional packaging system doesn't work well with proprietary applications. Maintenance of that package is a headache and hard to keep up with, which could take as long as six months to get updates out to users.

Snaps restructure this model to scale out. A developer will not need to prune through thousands of applications (dependencies included) and validate each. Underneath this model, the focal point of software development and publication is shifted away from the distribution, and control is given back to the software developer, thereby establishing a more direct link between the developer and the user.

The snap model allows the end user to vet the software publisher and not go through the Linux distribution. This enables higher-quality apps, and it will make those same apps more portable. Anything originally targeted for Ubuntu does not have to be used on Ubuntu.

Felix Riesberg: We [at Slack] offer Debian packages as an alternative, and there are no plans to take that offering away. But the reason we chose snap was that it greatly reduced the headache that came with updating software applications. Development cycles were shortened and much more frequent. We are able to get our updated desktop application to users much quicker. This is not so much a feature-based argument as it is a security one. Software isn't perfect. Snaps make the update process very quick and easy. Versioning is also challenging with Debian packaging. Snaps remove that pain. It also helped us remove the burden of dealing with versioned dependencies and rebuilding those same packages across multiple versions of that same distribution.

Snap or DEB, at the end of the day, I will build whatever my customers need and want. At Slack, we do not want to take these options away from our users. I do believe that whenever you want a technology to be successful, snaps may be the better option, but I also do not believe that taking anything away will be the way to go either.

PK: Felix, with snaps, how frequent are you able to get updates to your application's users?

FR: About two to three days.

PK: And how does this compare to the traditional packaging system?

FR: Sometimes our users are just stuck. Not all users will run an apt-get update. Unless the app screams or we give them a banner (displayed in the application) that a version is no longer supported, updates happen less frequently, if ever. Also, in certain versions of those traditional packages, the libraries and dependencies may be too old to support new features and bug fixes.

PK: How integrated are snaps in the latest Ubuntu 18.04?

ED: It is very much integrated today—so deeply integrated that you just wouldn't know whether you are installing a package from a snap or a DEB file. Even traditional APT works with snaps. As a result of this integration, the time spent hunting for PPAs is greatly reduced. Just browse for what you want and install. It's that simple.

PK: How does snap and the entire Snapcraft ecosystem better enable software developers?

ED: What most folks may not realize is that snaps have been around since before Ubuntu 16.04. Since then, snap usage has been growing, and adoption is continuing to look great. It's now a proven technology. Just to put this into perspective, there have been more than a million snap installs in the past month.

When it comes to software developers and providers, third parties tend to prefer the Ubuntu ecosystem, and with snap being cross-distribution-compatible, that same group of developers can easily push their games, applications and more over to the other Linux distributions.

FR: I would like to add that one reason why Slack was able to move to snap so quickly was because of Canonical's help. Throughout the entire development process, they were extremely supportive and responsive to our requests. It was amazing to see. Canonical was very willing, from beginning to end.

ED: [Directed to Felix.] That is because we do not want to waste your time. We just want to help you do what you need to do. We want to create developer outreach by showing up and helping out.

PK: Evan, what will Snapcraft look like in the future?

ED: Snapcraft will be more automated in that it will rebuild the package on behalf of the developer, if and when vulnerabilities are discovered.

Today, if you build and push to our app store, a manifest will be sent to Canonical. Canonical will send an email to inform you that your dependencies are vulnerable to security flaws, when they are discovered. In the future, we envision that we will automatically trigger a new build to address such vulnerabilities for you. As the developer, all you would need to do is review/test the build, give it a thumbs up and push the newly built package to "stable". Although, it should be noted that we are still evaluating this functionality and have not internally committed to it.

PK: Gentlemen, on behalf of Linux Journal, I'd like to thank you for the spending this time with us and for sharing your thoughts and experiences with our readers.

To learn more more about Snapcraft, visit here, and to learn more about Slack and its wonderful collaboration platform, visit here.