[tvb12]

Distribution is important -- I can't financially support the program if I can't install it on my computer.

However, my money can only support a finite amount of effort. Every bit spent on packaging is taken away from improving the actual program, which is what I really hope I'm paying for.

[woodruffw]

> Every bit spent on packaging is taken away from improving the actual program, which is what I really hope I'm paying for.

Sure, so the reasoning goes: you make it as easy as possible for the 95% of users who like your software (but not enough to change their host to install it), and hope that the remaining 5% are die-hards who are willing to do it themselves. That's why Sublime Text supports the five flavors that it does.

Put another way: you can make it so that your engineers spend almost none of their time on packaging, but your average user isn't dedicated enough to wade away from their default packaging ecosystem. Better to spend a very modest (as other commenters have pointed out) amount of effort supporting the common package formats than to throw those users away.

[tvb12]

I probably have a bad impression of how much effort is required to maintain packages for various distributions, then.

My only remaining point is that AppImage is supported by all of the distributions they support, as well as a few they don't.

[chousuke]

Building distribution packages really doesn't take all that much effort if your build system is sane, and once the initial work is done, your CI will let you know when maintenance is needed.

When you're building your own packages, you can reasonably take shortcuts that distros would not allow (like internet access during build, or vendoring some tricky dependencies), so for many things the packaging just amounts to specifying your dependencies, running your build, and perhaps applying some distro-specific tweaks.

[nly]

This is true, but a lot of the Debian tools are open source biased in that they really don't want you putting together binary packages that install things in to /opt, and don't provide a super convenient way to determine binary package dependencies without going through one of the debhelper build scripts