Canonical's Martin Wimpress addresses Snaps, Flatpak, and other competing standards, and community unease around Canonical's control of the Snap store.
For roughly two decades, Linux distributions have been the first choice for servers. Hardware support for Linux on the desktop has historically been an encumbrance to widespread adoption, though support for modern hardware on modern distributions has progressed such that most hardware is detected and configured correctly upon installation.
With these advances in hardware support, the last significant challenge users face when switching from Windows or Mac to a Linux distribution is app distribution and installation. While distribution-provided repositories are useful for most open source software, the release model of distributions such as Ubuntu or Fedora lock in users to a major version for programs for the duration of a particular release.
As an example, LibreOffice 6.2 was released on February 7, 2019, though this new major version was only delivered to Fedora users with the release of Fedora 30 on April 30, 2019, while users of Fedora 29 continued to receive security fixes for LibreOffice 6.1. The use of self-contained applications, such as Snaps in Ubuntu or Flatpak in Fedora, allows applications and their dependencies to be updated out-of-band.
SEE: How to choose between Windows, macOS, and Linux (free PDF) (TechRepublic)
Likewise, packaging proprietary applications (e.g., Skype) that work reliably across distributions is a challenge for software developers. Snaps and Flatpak are popular solutions for software vendors to support a wide variety of distributions without the need to individually compile applications for each distribution.
Adoption of these self-contained application packages is not without detractors. Because of differences in how they interact with the underlying system, certain configuration tasks are different between Snaps or Flatpaks than for directly-installed applications. Likewise, initial commits for the Snap and Flatpak formats were days apart—while the formats were developed essentially in parallel, the existence of two "universal" package formats has led to disagreement about competing standards.
TechRepublic's James Sanders interviewed Martin Wimpress, engineering manager for Snapcraft at Canonical, about Ubuntu's long term plans for Snaps, its adoption and support in other Linux distributions, Canonical's position as the operator of the Snap Store, and the benefits Snaps provide over Flatpak.
(This interview was lightly edited for clarity.)
What are the practical benefits of Snaps?
TechRepublic: Practically speaking, there are two competing standards for cross-platform application packaging—three, if you count AppImage. What's the practical benefit that Canonical's Snap format offers over Flatpak or AppImage?
Martin Wimpress: If you look at the initial commits of both of those projects, Snaps have a lineage back to Click packages, which were developed for [Ubuntu Phone] originally. The Snap project developed out of what had been learned from doing the phones, with a view to solving problems in IoT. So, although technically snapd and xdg-apps—and consequently Flatpak—look like they emerged around the same time, Snaps can trace their lineage back to the Click project from several years previous.
If we're looking at Flatpak specifically, we can probably include AppImage in most of these comparisons as well. Some of the similarities are that Snaps are self-contained software packages, which is something that Flatpak and AppImage strive to be as well. I think that Flatpak achieves that better than AppImage. I think AppImage still makes some assumptions on what's installed on the host operating system. It doesn't bundle everything inside the AppImage.
Similarly, Snaps, Flatpak, and AppImage work across all the major Linux distributions without modification. We haven't all arrived at this solution by accident. We've clearly, independently, all realized that this is a problem that we need to solve in order to encourage software vendors to publish their applications on Linux, because Linux is a very broad platform to target. If you can lower the hurdles… to getting your software in front of users on Linux, then that's a good thing. And we're all aiming to do the same thing there.
Where Snaps set themselves apart from Flatpak and AppImage is, with a Snap, you can target any class of application—be that a desktop application, or something for server and cloud, or something for IoT.
Certainly we're seeing a lot of success around Snaps on the desktop, with lots of major ISVs publishing their headline application as Snaps, and I'm very proud that we've attracted the likes of Spotify, Skype, Slack, and Visual Studio Code to Snaps.
Then you've got more server-oriented publishers such as Nextcloud and Plex who are also publishing [Snaps]. All of the major public cloud platforms are all publishing Snaps of their essential tooling as well, which is being used on a daily basis, at a vast scale, for their operations and for their customers.
Then we have the IoT story. This is interesting, in that the IoT story for Snaps is really the origins of what Snaps were designed to solve. In tandem with Ubuntu Core—our Ubuntu version specifically designed to enable device manufacturers to rapidly bring IoT devices to market, and maintain the security profile of those devices for the long term, which has been a struggle for those kind of device manufacturers and vendors to overcome in the past. They felt they've had to do a lot of the heavy lifting for themselves in order to maintain the security profile of those devices.
So that's one area where Snaps differ. If you look at something like Nextcloud, that Snap has many moving parts inside it. As a user, that's a single click to install through the graphical UI, or it's snap install nextcloud at the command line.
As a consumer of that Snap, you don't have to have any appreciation of the fact that there is a MySQL server that has had its schema set up for you. There's a Redis server in there, load balancer, PHP, and a whole bunch of other things as well that facilitate that Snap to work.
So one of the advantages is that snap install name-of-application, you can do that for simple apps and very complicated apps, and it really makes the end user documentation very simple.
It's great for publishers because it means that the accessibility to their software has a low barrier of entry for the users that want to use it. Now, for some Linux users, they will be quite happy, more than happy to spin up a Docker container or LXD container or a virtual machine and put all of that stuff inside it. But not all Linux users are sysadmins by day. So we're enabling a whole class of users to access complex software in an easy-to-consume way.
TechRepublic: Would you characterize Snap as being easier than Docker?
Martin Wimpress: Snap is not necessarily a replacement for Docker. Snaps can do some of the same things that Docker can do. Then you have to consider that you can snap install Docker, Kata Containers, and LXD. Snaps use container primitives—the same container primitives that Docker and LXD and other things use—so they share some of those characteristics. But I wouldn't say that Snap competes with Docker or replaces Docker.
Is it easier for an end user that's never used Docker before? I would say so, yes.
Who has editorial control over the Snap store and platform?
TechRepublic: With Flatpak, you're not really tied to Flathub. Why would Canonical's approach to having a centralized Snap store be advantageous?
Martin Wimpress: There's a number of reasons, and those reasons are as a result of having delivered software to Linux and Ubuntu users for many years, and learning from the things that we've done right and also the things that we've got wrong.
The central app store is something that people are generally comfortable with now. The phone in your pocket has a central app store behind it. If you buy a computer that's pre-installed with Windows or Mac OS, there is a central app store behind that. Yes, there are mechanisms by which you can install your software via other means, but there is a central app store available for you there. What we've learned is discovery is very important to publishers and also end users.
One of the phenomena that we were really interested to discover—we refresh the featured applications in the Snap store on a regular cadence. Every time we introduce an application into "Editor's Picks," which are presented through the desktop software center, they have a huge spike in installs and adoption. What we've learned here is that end users… actively open the software center, and use that as a means to find new and interesting applications.
Now, we're doing some more there to better curate that experience to better spotlight the good stuff that exists in the store, so that people can find the things that they're interested in with greater ease. What we learned from PPAs is it's a poor user experience, having to connect a third party thing in order to then install software.
If you are just able to access the app store—the Linux app store in this case—and install the software that you want, that's a really good user experience for the user. it means that the ISVs, be they large organizations or independent developers, are entirely in charge of the software delivery life cycle for their application. They choose when they want to publish. They choose when the application goes into the stable channel such that it's available to the majority of users. They're able to choose when it goes into candidate and beta channels. They're able to hook up CI to the edge channels so they can be continually publishing software and have people opt-in to these different risk channels based on whether they want the latest [build], or they're conservative and they just want the stable releases when it trickles down to them.
That whole notion of discovery is extremely important, and one that we didn't appreciate when we started out. When we talk to ISVs, publishers, and developers now, we lead with the story about the app store because this resonates with them far more than a simplification of packaging or confinement or automatic over-the-air delta updates.
What they care about is being able to publish on their release cadence, being able to put their software in front of as many people as possible, simplify the discovery and installation of that software, and being utterly in control of when they release.
The other thing about releasing is, in the past, you would release your application on your own website. I won't use brand names, but [imagine] you are a publisher of a bit of software and you put a .deb on your website—and that's great for Ubuntu users—but you install that .deb running Ubuntu 16.04, and then Ubuntu 18.04 comes out and you upgrade. Now, dependencies that the application needed no longer exist, because it's a flag day, underlying libraries have been updated, and that application breaks.
When you're using Snaps with everything being self-contained, you don't have these flag days where everything breaks, because Snaps will run back onto distributions in the past, and the same Snap will roll forwards to work on distributions in the future—without any changes—because everything is contained and isolated.
TechRepublic: Community members have expressed concern about the Snap server being proprietary software. What would be needed for a third party to operate its own Snap server, if it wanted to do so?
Martin Wimpress: When the store was originally created, it evolved from the Click store. The reason why the Snap store is proprietary is partly due to that legacy. In the early days of that transition from Clicks to Snaps, the store iterations were somewhat experimental to see what was working well for people and what was not, and it evolved quite organically.
As a result, the Snap store now integrates with other areas of the Canonical infrastructure. So the Snap store isn't a single thing. It's not like this one piece of software that you can easily decouple from the rest of the machinery that powers the infrastructure at Canonical. So we can't just pull it apart and separate it and say, "Here you go, here's the open source Snap store." Even if we could, we would have to very carefully consider undertaking that initiative because we've been here before. We were criticized for Launchpad, which was originally under a proprietary license and operated entirely on the Canonical infrastructure, and the source code was unavailable.
[Launchpad] is also a large and complex application that requires extensive infrastructure. People draw parallels to GitHub, it is not GitHub. It has source code hosting and issue tracking, but that's just a very small part of what it does. It runs a farm of build servers that can actually rebuild across multiple architectures and stitch ISOs together for all of Ubuntu and its flavors and produce those within minutes on demand. So it's a complex bit of machinery. But, we did eventually answer those calls to open source Launchpad, and we took on the cost of doing that work. As far as I'm aware, there is still only one deployed instance of Launchpad, and that's the one that Canonical hosts, and there have been no significant contributions to Launchpad from non-Canonical employees since Launchpad has been made open source.
So, if we were to open source the Snap store, does that actually benefit us in any meaningful way? History shows that perhaps it doesn't. That's not to say that we may not open source in the future. We'll just have to see.
How the Snap store works in other Linux distributions
In July, Linux Mint lead developer Clément Lefèbvre called out Snap as "a threat" following plans to provide the open-source Chromium browser (which is Google Chrome, minus Flash and proprietary Google components) only as a Snap.
Lefèbvre also takes issue with the relationship between the Snap store and Ubuntu as Canonical products, stating that "[users] shouldn't be told about Ubuntu and Ubuntu One when downloading software," and "software shouldn't be designed and tested primarily with another desktop environment and distribution in mind, and when he looks at screenshots he shouldn't see Ubuntu everywhere," adding that "It's wrong for Spotify to do that and it's wrong for any vendor to think that such a store can be the only store for all Linux users. For this to work it would need to be governed by us all, with clear goals, without bias and without conflict of interest."
Martin Wimpress: We've gone to great lengths to make sure that Snaps, Snapcraft, and the Snap store are disassociated with Ubuntu entirely. Obviously—like other projects that are sponsored by Canonical—it's a Canonical product in the footer of the pages.
You can put LXD, Juju, MAAS, microk8s, and many others in that bucket as well. But, we were very careful from the beginning to not make Snaps and Snapcraft and the Snap store look like an Ubuntu property, and more recently have even gone to the lengths that—for each of the publisher pages, if you publish a Snap in the store, it will automatically generate a distro-specific page.
To illustrate this, here's a link to install Spotify on Fedora or Linux Mint, as well as a generic page that covers all supported distributions.
Martin Wimpress: If we scroll down that [generic] initial publisher page, [there is a list of] users by distribution. We make it very clear what users of what distributions have this software installed, and to what proportion. You can see after all of the Ubuntus, Linux Mint is the next in the list, followed by Elementary, and then older versions of Ubuntu, and then you've got Fedora and KDE Neon and more Linux Mint in there.
We're trying our best to engage with these distribution communities at an engineering level. We hold a Snapcraft summit twice a year where we invite contributors from the community, people from the open source community, and people from industry to work alongside us. Our most recent one was in Montreal, and that was about five weeks ago. I think it was extremely successful.
People feel like we're being evil in some way by offering this software that we've helped curate, and bring publishers to, and making it trivially available to the other distributions as well. I really feel that this is a great example of "rising tides lift all ships." For example, the entire product suite from JetBrains is available in the Snap store. There's some really compelling developer software in there, and that's now available to all of the major Linux distributions.
We could have made snaps an Ubuntu only thing, but they're not. They're designed to be cross-distro, and available to anyone.
Will Ubuntu drop .deb packages in favor of Snap packages?
TechRepublic: Do you see a future for Ubuntu on the desktop—or for Linux on the desktop in general—where user-facing programs are distributed primarily as Snaps, while internal components would remain within traditional repositories?
Martin Wimpress: For the desktop distributions as they exist currently—and certainly for the flavors—that will be a decision for each of those flavors to make for themselves. There is no agenda within Ubuntu to move to that model currently.
There is some appetite to move some fast-moving applications to Snaps because it reduces the engineering burden on us, packaging software multiple times for multiple releases. You publish one snap—in this case, I'll use Chromium, because that's what's been debated among our user community recently. We published one version of Chromium that goes back all the way to 14.04, and it will work all the way into the future with subsequent releases of Ubuntu, so that minimizes our engineering efforts significantly.
So I can see there's an appetite to do those sorts of things. With Ubuntu Core, which I spoke about earlier, which is our immutable IoT-focused operating system where everything is a snap. The kernel is a snap, the underlying OS is a snap, and all of the applications that you install are snaps. But this is really for IoT.
But then, as a spin-off for getting display servers working for digital signage customers and kiosk customers, we've started to see these embryonic beginnings of proto-desktop environments that can run on top of Ubuntu Core. I know that that excites a number of people, not just within Canonical, but within the wider Ubuntu community.
Having a very tamper-proof desktop environment is kind of compelling, moreso as people become more aware of their digital rights and privacy, as we learn more and more about what's going on in the world around us and maybe some organizations who are not treating our data with the due diligence that they should.
So I could foresee that an Ubuntu flavor—maybe not even one of the existing ones—but a new one emerges that's built around Ubuntu Core and that uses snaps to put it all together.
TechRepublic: Something in parallel, like Fedora Silverblue?
Martin Wimpress: Yeah. Similar to that. We were here before—the phone project and the tablet project. This was how Unity 8 on those platforms worked, it was all confined. I can certainly see that happening, and there are a few missing pieces in order to fully facilitate that at the moment. I think we're seeing something similar to that emerging in general use at the moment, and not just with Linux users, which is this idea of moving your workloads and your applications into containers, particularly among developers firing up containers of your development, environment, workspace, and projects so that you can have all of these things isolated.
Developers have been doing this for decades with things like virtualenv to segregate Python development environments. We see the plugins now coming [in] Visual Studio Code that enable you to connect to remote instances. I think there's clear direction of travel here and among a certain audience, that's a direction that they will want to go in. There's no roadmap plans for that at the moment, but I think it will happen organically and I think it will happen in the community first.
Ubuntu's use of GNOME Software and GNOME's Snap plugin
TechRepublic: Canonical isn't going to ship GNOME Software (the default app installer in GNOME) in Ubuntu 20.04. Accordingly, Fedora is planning to disable the snap plugin for GNOME Software. This plugin was not installed by default, so Fedora's decision will impact relatively few people. What's going on with these two directions?
It really comes down to this: We are developing features within the Snap store—in terms of the APIs that power the Snap store—at a fast cadence. Backporting those features to the Snapcraft plugin for GNOME Software, and then subsequently backporting all of that into the various supported [versions] of GNOME software that go back across Ubuntu's history is becoming an engineering overhead that is hard to sustain.
The main motivation for going our own way on this is to ease that engineering burden so that we can move the desktop store at the same pace as the web store and borrow all of the design language that we have in the web store, in the new desktop application. It's just going to be more streamlined for us to do that.
[It] is important to point out is that we are committed to maintaining snapd-glib, the bit that talks to snapd, and the Snap plugin for GNOME Software, so that fast moving distributions like Fedora and Arch Linux always have current versions. The difficulty for us was continually backporting to older versions of Ubuntu to keep pace with our other development. Having GNOME Software be able to access Snaps is important to us for those people that are not on Ubuntu—of which there are many—who do want to access Snaps, and unsurprisingly, there are many of them as well.
For more, check outand on TechRepublic.
Note: Following the publication of this interview, a representative from Canonical told TechRepublic that "Canonical has not confirmed a final decision around the evolution of the Snap Store. Canonical is committed to developing and maintaining the snap plug for GNOME software."
- DevOps: A cheat sheet (TechRepublic)
- 10 free alternatives to Microsoft Word and Excel (TechRepublic download)
- Choosing your Windows 7 exit strategy: Four options (TechRepublic Premium)
- Microsoft Office 365 for business: Everything you need to know (ZDNet)
- It takes work to keep your data private online. These apps can help (CNET)
- The 10 most important iPhone apps of all time (Download.com)
- Must-read coverage: Programming languages and developer career resources (TechRepublic on Flipboard)