From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an example of toxic behavior on either side, they each had their motivations, and a consensus needed to be reached for both projects to proceed. From what I can tell that debate seems to be old news these days and I haven't seen as much clashing between those teams. I am not a developer on either side though, this is just from the perspective of a user who follows the Github issues.

And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it.

I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor.

This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.

I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, which is against the "do one thing per container" philosophy.

Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.

Sure but what ws their recommended way instead of putting systemd in the image, just use supervisord. Not even comparable.

Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.

I disagree that it was clearly wrong, because supervisord is a vastly simpler service manger than systemd. They wanted to put organizational pressure on people to move away from managing multiple units within a single container with an extremely complex octopus of a unit manager like systemd, and they arguably succeeded at that goal. (Even if it caused short-term discomfort for people who wanted to rely on systemd features within containers.)