Anachron 
probono@Anachron Imagine you run 5 different distributions. Do you want to download each application 5 times? I don't. Now imagine your are an application author and want to reach users of all Linux distributions. Do you really want to package your application for each distribution? I don't. But then, I'm the #AppImage guy ;-)
Damjan Jovanovic@probono @Anachron Exactly, 3rd party, cross-distro software installation is something Linux has sorely missed since the beginning. In the last 20 years, #Autopackage, #Listaller, #ZeroInstall, #OBLISK, #Klik, #AppImage, #glick, #Limba, and others have tried to solve it. Even #PC-BSD had #PBI packages.
@dcodejams @probono but there are package maintainers who are responsible to package and maintain programs for each distro.
All these solutions decrease the quality for all distros, which is another negative point. There is nearly no quality control when it comes to those repos.
And honestly, if the majority of developers have no problem with distro package managers and it's no advantage for the user, how useful is it?
All these solutions are use hostile.
@Anachron distros are often clueless and make packaging mistakes, or refuse to package software for political or legal reasons.
Upstream devs know their software best and have the greatest interest in keeping it working. Windows and macOS applications are packaged upstream.
Yes there are security and QA issues, but that's why #Snap and #Flatpak have sandboxing.
@dcodejams so you're saying a developer knows more about legal and packaging than the distro maintainers... which do nothing other than this?
You've also completely ignored that it's useless for the majority of linux users, even hurtful for many, because distros cant opt-out of telemetry, optional dependencies and alike.
Also, critical CVEs cannot be patched and shipped within hours, another issue for safety and stability that shouldnt be ignored.
@Anachron I both develop and package, and can tell you from experience, distro packaging is often broken or incomplete. Eg. the runtime dependency gvfs has on lsof (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254322) was only found accidentally, while developing gvfs code.
Distros don't stop telemetry in Firefox and Chrome even when they package them!
CVEs are a concern though. https://ludocode.com/blog/flatpak-is-not-the-future was proposing to link directly to distro binaries instead of the Flatpak runtimes that need to be patched separately.
@Anachron @dcodejams I am starting from the assumption that application software should be written, packaged, tested, distributed, and supported by the author. Just writing source code, throwing it into the wild and hoping for the best is not going to create a polished product.
@Anachron @dcodejams For example, a painting application I am using is using a finely tuned Qt stack with carefully picked versions and lovingly crafted patches. It just doesn't perform the same way when thrown at some random Qt version some random Linux distribution happens to have randomly picked on the basis of random policies.
@Anachron @dcodejams What a giant waste of resources to package every application for every distribution. And unsupportable due to the sheer mutitude of library combinations. Only with upstream packaging, where the application author (who knows how the application works) does the packaging, the application author can ensure the overall experience and give overall support.
@probono @dcodejams I'm sorry but I've seen so many and so horrible packages that application developers own that I've lost my faith in that.
Surely, in an ideal world, every application developer should know what's best and should also act on the interest of the users.
But since we experience a massive amount of opt-out (or even patch-out as I'd like to call it) and the quality of apps is going downhill, I am not trusting this approach anymore.