Is there a story of someone actually getting sucked into doing, say, Debian maintenance within the past five years?
I mean, they have a command line program to report a bug. That and their monstrously complicated packaging apparatus would make me think someone at Debian considered the sucking-in of people to be unethical and thus designed their maintenance polices to prevent it.
.debs are gzip'd tar file with predictable top-level folders and some manifest files. An APT server can be as simple as an FTP site, again with a predictable hierarchy and some manifest files.
Keysigning gets a bit messy but it is still relatively simple.
You can set up your own private package repository in minutes using nothing more than ftpd, gpg, mkdir, and vim.
The documentation is clear, comprehensive, and relatively easy to read.
Try to build deb package according to packaging guidelines.
If you are new to debian packaging, make a reservation in your calendar for several evenings, just to figure out what exactly you have to read through.
Did that. Ran an internal APT server for years. Was a fantastic system for doing remote installs on field installations.
Like, you create a folder structure that mimics the final installation inside one of the two toplevel deb folders. The other folder had a manifest or two. Worked easy, and did not take long to figure out
In that src file are things like "usr/whatver", "opt/whatever", "etc/whatever" and "DEBIAN"
In DEBIAN is a really simply control file and sometimes some scripts to do things on install.
Getting a package approved by the debian maintainers is an issue if you don't follow the guidelines (and lintian will help) - just like getting a package approved by the redhat maintainers, but to make your own deb is barely harder than creating a tarball.
That's why I qualified it "according to packaging guidelines".
And I don't want to comply with packaging guidelines because I want to get it into the upstream repo; no, I want it compliant so it is not broken at upgrade time and I don't want to have to solve several problems at once at the most inconvenient time.
With rpm it is both easy and piecemeal - you don't have to have the entire knowledge in your head upright, you can improve it continuosly. You start with spec file and rpmbuild, then find out about rpmlint, then you will find out about mock (so you can build package for Fedora-any version and CentOS-anyversion from any distribution, including Ubuntu or Debian, inside chroot or container) to koji (full blown distro-scale build system).
There's a difference between software evolving and drama. I'm trying to remember an upgrade to Ubuntu or Debian that led to as much manual intervention as the latest update to MacOS or Windows 10.
The only real time I can think of where they caused any impact to the end users would probably be when they changed up a bunch of software because of licensing issues -around 2001 or so. That also led to them writing or re-writing a lot of software and gave us pf, too. So I'd call it a net gain, personally speaking.
On the linux front -libc6 and the elf change-over caused a lot of breakage; like you said -I'm not sure if I would call that "drama" or not.
Perhaps the difficulty here is that different people are using the same words to mean different things? I would have said that drama and controversy in this case were nearly synonyms, but it sounds like you're using drama to talk about instability in the product instead?
Controversy is a less emotionally loaded term for the same thing (drama/dramatic, toxicity/toxic, harmful/harming). Because of that, it receives more credit in a logic argument.
You are on about direct user impact, where a project discontinuing is perhaps an ultimate one (EOL being moved 8 years in advance is almost that).
Regarding OpenBSD, that isn't the only occurrence. You can grep mailing list archives for some keywords. Look at how people like Daniel Hartmeier, Niels Provos, and Wim Vandeputte got treated. Sure, it did not cause OpenBSD to collapse but I would say it was controversy.
You must have missed the FreeBSD code of conduct change 2 years ago and all of the port maintainers who left as a result. I’m not even a FreeBSD user but heard about it.
It’s easy to get sucked in.