Quoting Craig Sanders (cas@taz.net.au): [init systems:]
the majority had no say in it, and probably aren't capable of switching to something else if systemd doesn't meet their needs.
They can follow recipes, though. There's a continuum from people who can fully maintain software through people confident patching and building software, to those who can manage a few local packages and some third-party package repos for particular purposes, to those fearful of or unable to handle doing _anything_ non-default. All but that last category _can_ follow a recipe. (If they're willing, and not just heady with the recently trendy appeal of being outraged on the Internet.) I wrote a recipe telling all about how to make current Debian 8 'Jessie' use either OpenRC or your choice of the other packaged init systems _partly_ to make a point to the Devuan crowd -- that the people loudly claiming Debian is now systemd-captive are mistaken, and are indulging gratuitous melodrama. (This was not entirely well received.) And, of course (equally), I wrote said recipe to assist those seeking such a recipe. I fully concur with Russell that most Debian users really neither know nor care about options among init systems -- for the simple reason that most *ix users, at all times, seldom even think of such things. (But I would assert that those of us who value reliable system, deterministic operation and security do.)
so it's OK to break promises because some (other) people said some mean things somewhere along the line?
right.
i think what actually happened is that they knowingly lied just to get their preferred option approved, and actually had no intention of enabling or even allowing continued support of anything except systemd.
Quite possibly, but this needs to be seen in proper context. IIRC, it's things like 'daemon package [foo] has an unfixed bug in its SysVInit script'. (Invented theoretical example, because I can't be arsed to find a real one.) In which case, guys, your hands aren't broken: Make whatever's the obvious fix. If you're a Debian developer, do a NMU. If you're not, put it up in a local repo. Either your patch will get merged or perhaps your superior outside package will embarrass the DD into doing it right _or_ your package will become the standard version. I've been pretty lazy in the past in allowing bloat and questionable architectural decisions to enter my systems via Debian package dependencies, but I finally got my attention drawn to the problem -- and it wasn't systemd but rather the whole stack of rather ridiculous desktop-computing glue creating a dependency hairball: systemd, udev (now a wholly owned subsidiary of systemd), PolKit (policykit-1), udisk2, packagekit, network-manager, systemd-logind, D-Bus. IMO, those bits of CADT-ware don't belong on my systems, particularly servers, and mine is the only opinion that ultimately matters locally, so I set about getting rid of them. No polemics required: It's merely a technical task, and not actually a particularly difficult one. As I showed on my Web page. Further, if Debian package maintainers make stupid decisions over time, I can correct those. A .deb isn't exactly difficult to understand, dissect, change, and rebuild, after all. So, noisy politicking isn't required, and IMO is almost always a rather poor way to get real-world objectives achieved. (Speaking of politicking, I note with amusement the spin-aspiring Subject header. Russell, I'll bet that was yours, right? Here, let me help: https://en.wikipedia.org/wiki/Begging_the_question )
By inclination, i'm in the anything-but-systemd camp because systemd is the only one that's actively hostile to other software that it sees as competing with it (now or in future).
At least some in the Debian community are particularly annoyed by the systemd team's unwillingness to take patches for portability to kernels beyond Linux. That led Adam Borowski to jokingly dismiss OpenRC because it lacks "a hostile upstream". https://lwn.net/Articles/511726/