Justification to Supporting Snapcraft as a Developer

I am a long time developer. I work with my friends to build and ship applications, and we all love Snapcraft and Flatpak, though none of us have created AppImages. There is a lot of reasons we love Flatpak, but all of us can easily describe Snapcraft as the godsent of software distribution. While not without its flaws, and there are many flaws, it is an overall near-perfect system. Snap being near-perfect isn't just an opinion, but mathematically provable to be the current best. We try to support anything that is not past the end-of-life cycle. Supporting this many distributions is down-right near impossible for a small development team, especially one made of friends who only help each other because of our friendship. What I want to prove is the mathematical proof developing for Snapcraft is better than packaging for the distributions itself.

There are the distributions of Linux we support. Let's take the four we put extra focus on, Ubuntu, Manjaro, Solus, OpenSUSE. We run into issues already. The problem currently is that there are four package managers we need to add our package to their repositories. While we never uploaded packages to Solus, we still tried to support it in some way. Due to time constraints and general knowledge, the editions of Solus and Manjaro will count as one release each. The reasoning being that Manjaro is rolling, and Solus isn't entirely clear on EOL dates. OpenSUSE starts difficulty as we need versions readily built for the current release and the next release, also tumbleweed. The current total of versions to maintain is five. Ubuntu makes things stressful. Taking full LTS to the maximum level, there are four LTS editions to work on, as all four are not past EOL. Not including end-of-support (EOS), as EOS means that Canonical doesn't support it, developers still should. The 14.04 LTS expires in two years when the next LTS releases. There is also two mainline release that expires a little after the following version. Two mainlines bring it up to seven release updates, and the four LTS brings it to eleven. Then you have twelve for the in-development editions, ones that can be downloaded and tested. That usually is only one, being the next release. That makes twelve editions of support, some of which need special modifications to work. We can ignore situations like 18.04 still supporting i386 because a simple setting the architecture to all fixes the issue for our software.

To solve this, we need two variables: the total of versions per system we support, and the sum of those. We just explained how many there are, but that is a total of twelve. Twelve times the number of applications, multiplied times the amount of time dedicated to building and uploading - on average thirty minutes. That is six hours per package. I have not been in contact with my friends in a bit, so I am unsure if they have made new applications or deprecated old ones. I am also not sure if they started to support Snap yet, either. I last worked with them on about ten or eleven projects at any given time, not including libraries we created for the apps (lost count). That means we would spend almost three days building and shipping each package to each supported version of the four operating systems.

If we instead built snaps, we would build eleven packages for one system, taking the same thirty minutes. Once per each of the eleven packages, that would be thirty times eleven, being 330. Turned into hours is roughly five and a half hours. That is quite literally twelve times less time taken to build and package each app for multiple systems and practically infinite versions.

By going with uploading to each version, it took sixty-six hours. Snaps are only five and a half hours. It would take a month's worth of time to support every distribution individually per year. On the other hand, building snap packages would take the same amount of time per year as building every single application per month if we produced for each version of each operating system individually. That is an eight-hundred percent decrease in human resources. Not to mention we also get the benefits of other distributions we don't actively package for, without the extra time spent to package for that distribution and all of the versions it has in the active life cycle.