But in the situation that a new version of the software is released, and I think it would benefit me right now, I'd trade all those downsides for being able to

But in the situation that a new version of the software is released, and I think it would benefit me right now, I'd trade all those downsides for being able to use that software right now than waiting to be included in my distro (like it happened to me with Gimp some years ago). I don't understand what static linking vs. dynamic linking has to do with waiting for gimp to be included in your distro? I'm plenty of memory, storage and bandwidth but not so much of time to compile it by hand. No one is suggesting you have to do that, but someone will have to do that, and it does require resources (time, people, hardware, etc.). I have to admit that this is just a workaround while we find a better software release and dependency management system. If by system, you're referring to technology, then I disagree. In other words, the technological constraints of today's package management systems are not the primary issue, rather it is how the software itself is being developed and managed and the available resources to do so. Ultimately though, most of this all comes about because the underlying systems that applications depend upon in a typical Linux distribution are not properly release engineered. They don't properly version the shared libraries, they don't carefully avoid incompatible changes in interfaces, and they don't have sufficient regression testing. So to me, the right answer is to fix the root of the problem, not paper over it by pretending there isn't one by essentially embedding copies of every dependency into an application. In short, start encouraging developers to reduce their dependency chains, properly release manage their software, ensure that core system components offer stable interfaces, and provide timely updates.