The specific systemd drama the parent is referring to was really Debian drama and the requirements put on maintainers to support alternative init systems. If upstream drops support for non-systemd setups do the maintainers have patch in support? If upstream now has a hard dependency on systemd do maintainers have to patch it out?

Red Hat wasn't involved in any of the drama outside of being the ones writing and funding OSS software for themselves.

Redhat was involved because they heavily maintain some of the upstream packages that put in a hard systemd/logind requirement (GNOME), thus forcing Debian into the uncomfortable position of taking on a large compatibility project, when upstream could have instead taken small patches to continue to maintain compatibility with non-systemd systems.

Which packages had a hard systemd/logind requirement upstream? As far as I understand it, GNOME still gets upstream patches from BSD developers and is still supported there. (Some Debian packages do have hard dependencies on systemd, but this is a downstream packaging issue)

I don't want to leave my hearsay uncited, but try here:

https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...

Slightly more recently:

https://digitizor.com/gnome-linux-only/

This was an eternity ago in internet time, and I'm not all up and up on BSD development, but maybe enough folks are keeping it going on BSD nowadays?

Interesting, I checked and the only upstream component of GNOME I could find that requires systemd and doesn't have a compile flag for it is gdm. This isn't required to start GNOME (you can use any other display manager) and FreeBSD/OpenBSD seem to be maintaining consolekit patches for it downstream. So I see why there is little incentive to fix this upstream. (On non-systemd Linux distros the focus has shifted to staying compatible with elogind, but that doesn't work on BSD)

But as a user I basically didn't have to care about the details and the "drama" aspects of that drama (I had the result to deal with of course)