I generally agree with this article, with three exceptions: 1. It's helpful to distribute a statically-linked binary for users of distros that don't yet have p

I generally agree with this article, with three exceptions: 1. It's helpful to distribute a statically-linked binary for users of distros that don't yet have packages. 2. It's also useful for situations in which distro packagers will want to make suboptimal packages. For instance, pretty much every single Linux and BSD distro builds chromium with varying levels of weakened security; some disable CFI and others use unsupported toolchains without the right hardening features. In the context of software that needs to be built with strict toolchain hardening and rapid updates, it can be quite useful to use "official" builds that check those boxes. 3. Reproducible builds: developers are in a good position to ensure their software works well in a reproducible pipeline. The best way to do this is to build reproducible binaries themselves. Once they have such a pipeline set up, they should make binaries (or at least checksums) available so others can try to reproduce those builds or report bugs if they can't. This is a good example of a situation where the line between "developer" and "packager" gets really blurry. These three reasons have overlap. A reproducible build with maximum compiler hardening flags can provide assurance of the package's security; if a distro maintainer finds that enabling those flags causes a crash, they can compare against the reproducible build to better understand the issue. Beyond these three reasons, packaging is best left up to a distribution.