Flatpaks have json metadata files. AppImages have an AppDir. Snaps have a snap dir. If someone contributes one or more of these to a GNOME project (or any other upstream open source project for that matter), it enables a wider distribution of the software. However, depending on the project maintainer, not all of these packaging bits are welcome. Rejections of this kind causes unnecessary friction when we are all here to improve and promote open source software. This post will focus on snaps and point out some reasons why each maintainer should not only accept snap metadata, but encourage it.
Automatic Builds
If there is snap metadata in a project, then snaps are being built on launchpad. A build on launchpad is triggered whenever there is a new commit in master or the latest stable branch (ie. gnome-3-34). The snap built (on launchpad) from master commits is automatically pushed to the “edge” channel (think “bleeding edge”) and the snap built from the latest stable branch commits is automatically pushed to the “candidate” snap channel. After the maintainer of that snap in the snap store tests the candidate snap, they can go and move the snap to the “stable” channel.
So by just committing to master, you are getting the updated snap into the edge channel and making it automatically available to the many many users of snap!
More Testing
By providing your changes to users so quickly, you expedite the testing! More testing means more bug finding and reporting – not just snap related issues.
Maintenance
We understand that not every maintainer is familiar with snapping things. Snapcraft folks are happy to assist project maintainers in building and testing changes to snap metadata. To reach us, everyone is welcome to post a question to the very active forum.snapcraft.io or ask in the #snapcraft irc channel on irc.freenode.net.
If a maintainer is not interested in even touching it, then we are happy to maintain the snap metadata.
By accepting snap metadata into your project, you are casting a wider net for users to learn about and enjoy your software. More users means more testing and more bug reporting. With all of this in mind, I hope maintainers will consider encouraging snap metadata in their projects!
Isn’t the point that a lot of GNOME contributers prefer flatpak (e.g. because it’s federated) and want it to succeed instead of snap?
Well both flatpak and snap have pros and cons. Yes, flatpak is federated but snap can have more than one app in the package (for example). If you’re specifically interested in the centralization, then we can talk about that.. Canonical has kept the snap store centralized to ensure that users get verified snaps, otherwise we have the ppa situation all over again – where users are installing random software from a random ppa that has a random amount of maintenance.
My point with this post was to not say that snap is better than flatpak or visa versa, but rather to say that all should be embraced. If someone submits snap packaging info to a project, this post points to the reasons why it doesn’t make sense to reject carrying the snap packaging info.