Any forks of systemd will have to be renamed to something obviously different from plain “systemd”, but forks already work that way. We are not, for example, using “XFree86” even though the current X Window System is derived from XFree86 code.
Nor must the program files (shell commands, etc) be renamed. OpenSSH still uses the program file name ssh for compatibility, despite “SSH” being a trademark belonging to someone else.
The only dogma systemd has broken is that booting has to be slow, complicated, and unreliable. Good riddance.
The only dogma systemd has broken is that booting has to be slow, complicated, and unreliable.
This was a solved problem before systemd was a thing. And, even if we assumed that Upstart (2006), OpenRC (2007) and others wouldn't have existed in 2010: How often do you need to reboot your system before the intrusiveness of systemd is worth it?
In Upstart's readiness protocol, daemons are expected to SIGSTOP themselves to signal readiness to the process supervisor. This design is extremely questionable, to put it politely.
OpenRC still relies on System V shell scripts, and therefore is not an improvement.
“[T]he intrusiveness of systemd” means nothing to me. I care about what it can do and how well, not whether it's liked by change-fearing graybeards.
The number of reboots required before the effort to learn systemd becomes worth it is approximately 1. Shell-script-based shutdowns frequently hang, and when they don't, they take 30+ seconds to shut the system down. Systemd can shut the system down in 5 to 10 seconds. Hallelujah and good riddance to what was one of my least favorite parts of the Linux experience.