This, but I want to add, I think the root cause is less due to the ease of writing a Dockerfile vs writing a deb, rpm, etc. and more due to the low cost of hosting. Whatever low-quality Dockerfile you write, you can sign up on Docker Hub, build and push there, and you're done. GitHub Packages doesn't support deb or rpm, and anyway for better or for worse, packages are tightly coupled to the distribution they're packaged for. That means either getting your package into the package repository of each distribution you want to target, or hosting your own package repository, which is non-trivial in both financial and labor cost.

Docker has a lot more crap, but it did dramatically lower the barrier of entry, which is a good thing. The proper response isn't to bemoan the lower barrier of entry, but to attempt to lower the barrier of entry of traditional packaging.

I have rarely seen end user software being distributed as a docker image, only server applications. Occasionally I see CLI tools that are hard to package available as docker images, but those are generally done because the maintainer hasn't provided precompiled binaries.

>He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc.

If that is a valid complaint, why does he choose two examples where that is not the case? Nextcloud AIO is just one option among many and certainly not the "standard way" of hosting your nextcloud instance. Coincidentally I came from hosting nextcloud the "standard way" and I'm really glad AIO exists and I don't have to manage nonsense like nextcloud ending support for the latest Debian php version. And Home Assistant is mainly distributed as the OS variant with the docker version being the step child afterthought that barely functions.

Don’t tell this guy about Helm-charts.

Oboy, if you thought docker images overriding default configuration options was bad. Wait until you add yet another layer of new config parameters on top, that do absolutely nothing at all, just translate down into an environment variable that the docker image translates into the application config. The ever increasingly popular ones from bitnami are the worst in this regard.

I always get questioned for reinventing the wheel when writing my own Dockerfiles. In the end it always end up more maintainable. The problem is these premade charts put a wheel inside a wheel inside a wheel. If you get a flat tire, you have to open up all of them at once to understand what is going on.