Linux Kernel. Git. $torvaldsinitsystem ?

You'll know there are too many dependencies on systemd when people who don't want it (Devuan, Slackware, openBSD) can't boot a decent system without it. I don't think we're in danger of that: people who don't want systemd don't need it.

Git did start as a tool, and has been extended, a lot.

The same than the kernel booting was extended across the years to cover usage cases.

If he writes pid 1 code by itself, to get rid of a issue, as he did with the kernel and with git, we will call it the Linus pid 1. But as others said, maybe he doesn't has personally annoying issues with this.

I'm not sure where this tendency of Red Had for taking over the ecosystem comes from. The only rational basis for it I can think of is they wanting Linux to stay complex, so they can sell support. But it's way more likely it comes simply by them hiring a big number of developers, and not having enough in-house problems to solve - after that they must lead, not follow (for marketing reasons), so they must push their solution onto everybody.

Within Linux. Systemd is explicitly anti-portability across Unixes, and encourages dependencies on it that make life increasingly hard for the BSDs, OS X, etc.

So, yeah, if you zoom out a little from Linux, systemd fits right in with the UNIX wars.

So in the end, because of compatibility shims on both sites - and that our software build systems have evolved to support multiple init systems, its largely a moot point.

Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

It could be that they both benefit from building complex systems and believe honestly that such systems are the optimal solution from their own perspective. This requires no bad faith or conspiracy theories.

Its simultaneously possible that such a complex solution is sub optimal for other parties.

They are under no obligation to build a solution that is best for other parties and others are under no obligation to adopt or like such solutions.

Its entirely possible for two parties to disagree without either being evil.

But then i start reading and seeing the guy name others from seemingly unrelated projects, thanking them for their efforts.

But lo and behold, once i start running the bloggers name, and the names he mentions, they all come up as Red Hat employees.

No it doesn't. Different OSS projects already compete with each other in many details of design and implementation. They try to win over users or mindshare instead of dollars. Some with financial backing also have dollars in mind. Even lock-in is approximated by things that many apps depend on but are too big to change without risking a break.

Let systemd try to take over whatever it wants. It is still LGPL licensed, so I can do whatever I want with it as well. Those writing it can do whatever they want - nobody has forced any distro to adopt systemd bseides Red Hat themselves, insofar as it was their project principally so of course their own distro used it.

Arch, Suse, Debian, Ubuntu... all game to use it under consensus. I personally think there is no better outcome than well engineered and linked software seeing uniform adoption to let the ecosystem move on to bigger problems. The degree to which systemd's pervasiveness has enabled the vast simplification and feature richness of so many disparate aspects of development on the platform only reinforces that belief - the ease of writing and shipping service, socket, requires, triggers, timer, mount, etc files. The ubiquitous availability of a session dbus. udev pervasiveness, cgroups already being there and setup, there is so much feature richness systemd gives everyone up the stack to claim shell scripts and grit were better is to say you should never stop reinventing the wheel to build the cart until the wheel is cast from solid gold.

Because they're willing to fund the work.

As for conflicting: i think you have missed server years of conflict, never mind that you can only ever have one process as pid1 on a unix setup.

And if something like your session tracker depends on pid1 being systemd, you get conflict.