You’re a company and your software actually runs on Linux. You want to reach as many people as possible. So you make a .deb for Ubuntu. Or you go with a package manager that is cross-distro.
And snap doesn't address the fact that the server components that talk to the snap 'store' software is closed-source and only available from Canonical.
Never claimed it did. Snaps are yet another half baked Canonical tech...
Those of us using immutable distros would love a "flatpack for cli utils". OS-tree layering defeats many of the points of immutability, and pet containers are a bigger pita than they should be. There has to be a better way.
ehhhh.... If I want to reach as many people as possible I would build rpm, deb, docker images, provide source code. I would not use snaps because it would imply more effort from the end user -- they first need to install snapd and only then my app.
Yup. This is what's true in my experience (working for companies that sell software that runs on linux distributions).
I don't have any gross snaps or unpackaged stuff on my laptop, how could I expect paying customers, with an operations department, to accept anything less.
> they first need to install snapd and only then my app
This is a reductive argument.
It's not more effort if Snap is already included in the Linux distribution.
This argument only applies if Snap is your only distribution channel.
Otherwise, you could say that distributing a Linux version of the software implies more effort from the user, because they'd need to install Linux first. We're talking alternatives here.
That’s why.