And you are. There is nothing technical which prevents you from installing a 3rd party .deb

I can't in this instance since the provided .deb does not run for me. I know it *should be possible, but the fact is: it is not for me. I blame the package/distro cruft situation for it. I think if we were using snappy for more than ten years, just like windows uses *.exe installers for a long time we wouldn't have this mess.

What makes you think that without maintainers you would have better chances to run the software you want?

I'm not talking about maintainers, but about maintaining. The act of having to care about things after code has been written, compiled and packaged for my architecture. There should just not be another step necessary. (I'm also not saying there should be no additional processes to guarantee security or quality or whatever: I say nothing else should be a requirement to run code.)

If upstream did the same thing with snappy (flatpax, whatever) it wouldn't have worked anyway.

The way I understood this is that those systems make sure that dependencies just are met. Even if it means shipping them extra. Am I wrong about that? I know that theoretically the deb could have done that as well. My limited understanding of things is that deb, rpm have a few thing in common: One is NOT to encourage doing this in the first place. I just assume that if we were living in a "snappy world" chances of me just grabbing that package and starting it successfully would be orders of magnitude more likely.

• I don't think it will significantly increase the actual quality of upstream packages: if upstream provides a .deb that doesn't work there is no real reason why they should start providing snappy packages that do

I do. If I were a developer and provide one kind of binary for all GNU/Linux users my incentives to make that one work are WAY higher than to always provide a gazillion and then finally and lazily point to some sourcecode that can compiled anyway - just in case.

• It won't take care of fragmentation (note that snappy is ubuntu-only, fedora (and other distributions) has flatpax, and then there is guix which uses a different approach, and...

Evidently it didn't yet. But it could. All I'm saying is that it should - or any other competitor.

• It will mitigate a bit the dangers involved in installing 3rd party packages, but it will leave other significant dangers open (see e.g. mjg59)

This appears to be real issue. Yet you're talking of a specific downside of snappy, I'm talking about the general benefits of something like snappy.

• it will mean more work for upstream, which could be more productively used to work on their actual software (unless somebody else comes in and... becomes a maintainer for the snappy/flatpax/whatever package)

My assumption is that it saves time for developers that package on their own. And maintainers would only have to touch things once instead of X times for X distros.

I'm no expert in this, I never ever release or packged anything. I am an expert in being a user in the GNU/Linux world that constantly points to breezingly fresh beatuiful, honey sweet, sugar coated and velvet soft binaries for all major operating systems and then either shove 5 year old versions down my repository throat - OR - point to some source code. Snappy finally looks like a scratch to my itch. Am I really mistaken here?