Mad respect to sales guy. I'm doing the same and avoiding arms companies (my background is very useful for military research).
I acknowledge some warfare may be legitimate (having been bombed myself), but arms companies don't stop at selling to your personal favorite army which you consider morally right, they keep looking for more business abroad.
I don't want to be the one realizing I'm sitting in a cozy air-conditioned office and having made money from the messed up warfare in some distant far-away country, having a large financial incentive to cause more conflict there.
I think in this hypothetical scenario the uid 0 attacker can create its own node for /dev/rwd0 and use raw disk accesses to get around filesystem limits.
I'm assuming you're talking about the reviewer and long term contributor side of it. personally I found initial setup as a drive-by contributor to be very tedious. GitHub is the lowest friction because I already have an account with SSH key etc.
As for NetBSD, there's hundreds of people with commit access and a small group of respected developers to resolve disputes, with some extra democracy / laws restricting it. FreeBSD is similar but I never bothered to check the details.
I think we generate less hackernews-worthy drama posts overall because when someone is repeatedly abusive, they're asked privately to stop/apologize, and if they keep at it, they risk being kicked from the project.
With hundreds of contributors and a weak hierarchy, no one person is too important to be kicked.
Linus Torvalds again uses abusive wording when he could've made his point just as clearly without it. As the leader of a project he should avoid that - it's massively detrimental that contributors fear being the target of his next rant.
Notify groups who have to develop fixes (in this case: OS, compiler developers). Especially when they have a record of not violating embargoes and good faith in fixing issues.
When the longer time for fixes is done, post an announcement in private pre-disclosure lists.
For a very complicated change, give a few days of private testing and provide patches and details to groups that must apply the patches (oss-sec distro list, etc.)
For a simple one with existing backports, notify that <DATE> is publication date for a type of vulnerability to <PROGRAM>.
Wait 2-4 weeks to publish a working exploit.
Don't notify bodies who don't have their own custom code that must be fixed, but happen to pay you enough money.
The latter is actually what happened in this case and it's immensely frustrating.