[lmm]

Systemd was designed in a way that was more tightly coupled than the alternatives and made adopting it an all-or-nothing proposition, and other projects (particularly Gnome) were also tightly coupled to it. It was absolutely foisted on people: a lot of people didn't want it but found they were nevertheless obliged to install it. The whole thing abused the goodwill of the free software community: systemd folks added systemd-dependent patches to other software, taking advantage of the norm of accepting such contributions, while refusing patches that made systemd compatible with other systems (e.g. non-Linux). And the end result was a state where you can no longer fork and replace components piecemeal - the whole free software ethos, the very reason GNU was built as a Unix-like system in the first place - which does far more to discourage participating in free software development than any mere internet argument.

[jle17]

The tight coupling, the non-portability, all of that are technical choices, that can be debated on their own merit without the need to attribute malevolent intentions to the developers.

Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything. People got systemd on their OSes because they chose OSes whose developers chose to move to systemd.

It's not like Lennart comes to your home with a gun if you install OpenBSD.

[dogleash]

> all of that are technical choices, that can be debated on their own merit without the need to attribute malevolent intentions to the developers

The ramifications of those technical choices on the software ecosystem are so well understood [0], that there is no point in discussing "their own merits" in a vacuum.

What's most relevant to my professional and waning hobbyist interests are the shape and trajectory of the software ecosystem as a whole. To talk about systemd without talking about how it's developers interact with the software ecosystem is to talk about nothing.

[0] I graduated before systemd was a glint in Pottering's eye, but we somehow still covered it in school. Not only coupling vs cohesion in the abstract, but also how various design decisions (including init system arguments of old!) interacted with the ebb and flow of unix-like OS evolution.

[lmm]

> The tight coupling, the non-portability, all of that are technical choices, that can be debated on their own merit

They can't. GNU was a political project from day 1, with explicitly political goals; the unix-like design is for political, not technical, reasons.

> Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything.

Citation needed. If you maintain a widely-used open-source project there's a pretty strong social norm/pressure to merge contributions that don't have anything obviously wrong with them, even if the functionality they implement is something you don't actually want or need.

> People got systemd on their OSes because they chose OSes whose developers chose to move to systemd.

Because they chose OSes whose non-technical leadership chose to move to systemd, in violation of the project constitution, and then had the rump technical committee rubber-stamp it once the principled technical leadership had resigned in disgust and the decision was already a fait accompli, the way I remember it.

> It's not like Lennart comes to your home with a gun if you install OpenBSD.

Some will rob you with a six-gun, and some with a fountain pen. No, Lennart won't hack into your computer with an SSH exploit, but he'll get the software you're using (like Gnome) to push updates that stop it working on your computer, and so the end result ends up much the same.