I am mostly in agreement with this article; releasing a tarball is a necessary and sufficient mechanism for distributing your software. If it is valuable enough

I am mostly in agreement with this article; releasing a tarball is a necessary and sufficient mechanism for distributing your software. If it is valuable enough, maintainers can use that tarball to package it. I strongly believe that my software isn't somehow "more special" than anybody elses'; users shouln't have to install my software any differently than others', or expect a different release cadence. For those unfamiliar with the packaging process, check out Fedora's `.spec` file to generate the RPM for rsync [0]. It contains instructions for downloading the tarball, installing dependencies from Fedora's repositories, build commands, and metadata. Tarballs can also be used to generate Flatpaks in much the same way; see the manifest file for qBittorrent [1] for an example. It is okay to distribute your own software, but only for development. End-users should not be expected to get your software from npm, PyPI, etc. when distro packages exist. That being said, it is possible for developers to optionally go above and beyond by: - setting up repositories for the latest stable release or prerelease, for those interested - Providing their own binaries/artifacts (if applicable) for anybody who wants to test software out before installing. These are not replacements for distributing a tarball that can be used for packaging; they are optional additional steps. [0]: https://src.fedoraproject.org/rpms/rsync/blob/master/f/rsync.spec https://src.fedoraproject.org/rpms/rsync/blob/master/f/rsync... [1]: https://github.com/flathub/org.qbittorrent.qBittorrent/blob/master/org.qbittorrent.qBittorrent.yaml https://github.com/flathub/org.qbittorrent.qBittorrent/blob/...