The internet is a fickle beast. Just when you think a company or community of developers have come out with a bit of technology that could help an operating system or piece of software rise above, that wacky internet sneaks up to say, “Nay, nay!”
I remind myself over and over to not read the comment sections. But I do, and I see the flame wars that once threatened to slice and dice the heart of Linux rise back up. Once upon a time it was vi vs. emacs and GNOME vs. KDE.
Then things sort of worked themselves out.
Until they didn’t.
Systemd decided the flame wars needed to be rekindled and boy, were they. To this day, there are those who despise systemd (though it’s here to stay).
But the community wasn’t satisfied with only one flame war, so it started another. This time around, it was snap and flatpak. However, this go round, something a bit different came into being. The snap/flatpak flame war wasn’t only pitting one against the other, it saw members of the community lashing out at both technologies together.
One reason for the vitriol against both snap and flatpak is how distributions are either defaulting to those technologies over standard package manager installations or how those same distros seem to be forcing either snap or flatpak onto the users.
I have a much different take–as you have probably grown to expect.
Let me set the stage.
SEE: Choosing your Windows 7 exit strategy: Four options (TechRepublic Premium)
What are snaps and flatpaks?
Before I dive any further, I should explain to those who don’t know what snaps and flatpaks are. Simply put, these are universal packages that are distribution agnostic. In other words, if your distribution supports snaps, any snap package will install. If your distribution supports flatpak, any flatpak app will install.
The one caveat is that snap won’t work with flatpak and flatpak won’t work with snap.
Apps, apps, everywhere
I get tons of inquiries about reviewing applications. On any given day, I see 20-50 emails from companies asking if I’d be interested in taking their apps for a spin. About 25% of those emails legitimately interest me and, of that 25%, maybe half of those are viable.
But, recently I’ve noticed a slight shift in what I’m seeing. For instance, take the email I received about an update to the Blue Mail client. I’ve written about this app for both Android (Top 5 email clients for Android) and Linux (Blue Mail now available for Linux) and found it to be an outstanding email client.
That email client is available as a .deb, .rpm, or snap package. I installed it via snap and found both installation and usage flawless. These days, however, more and more apps are being released as snap-only.
If you look at the Snapcraft Store, you’ll find apps like:
Postman – API dev environment
Beekeeper Studio – SQL editor and database management tool
Sublime Text – Text editor for developers
Skype – VOIP communication
Instagraph – Unofficial Instagram client
Rocket.Chat Desktop – Desktop client for Rocket.Chat
Mailspring – Email client for teams
Cloudtag – File sharing
Google Cloud SDK – CLI for Google Cloud platform
Bitwarden – Password manager
Guess what? Those apps are only available as snaps. Head over to Flathub and you’ll come across applications that are (surprise, surprise) available only as flatpaks. There are even apps, such as Nextcloud, that are available as snap packages. Why is this important? Because the installation of Nextcloud via snap is incredibly simple (read: How to install Nextcloud with SSL using snap). In less than two minutes, you can have Nextcloud up and running on a server, thanks to a snap package.
Of course, you can always install Nextcloud from source. Although that installation isn’t much of a challenge, it certainly requires far more knowledge about Linux than does the snap package install. The snap install:
sudo snap install nextcloud
Point your browser to the IP address of the server, create an admin user, and you’re done.
What’s more important
This is where it gets a bit feather-ruffling for some. I’ve reached out to a number of companies about releasing Linux versions of their software. In many cases, the initial “no” turns into a bit deeper dive, which goes something like this:
Them: Which distribution do we package for?
Me: The most popular?
Them: Which desktop environment do we develop for?
Me: The most popular?
Them: Which toolkit do we use?
Me: The most popular?
In the end, it turns out most software companies don’t have the time, budget, or inclination to answer all those questions and come up with a viable solution–one that will appease everyone.
However, with snaps and flatpaks, those three questions turn into one: Which universal package format should we use?
The good news is, for most distributions, it doesn’t matter. Take, for instance, Pop!_OS. On my distribution of choice I can install either snap or flatpak, so it wouldn’t matter which technology the company chose. Either way, I’m good.
But ultimately, what snap and flatpak technology does is remove the barrier to entry for many software companies. Or, if it doesn’t remove it altogether, it shrinks it drastically. That’s why so many applications, that might not otherwise do so, can make their way to Linux.
In the end, it’s about choice. I’m not talking about the choice between snap or flatpak. I’m talking about the choice between having big software companies eventually come around and release titles to the open source platform or not. I, for one, would rather see all of those software titles available for both Windows and macOS be released for Linux. If that’s to happen, chances are either snap or flatpak will make it so.
These universal packages aren’t so much about the present, but about the future. If the Linux desktop is to continue thriving and expanding, it will happen thanks to the help of snap and flatpak. Otherwise, Linux will miss out on a lot of important software titles.