But it's interesting the way the "Gods of BSD vs the rebel alliance"
thing seems to have inverted itself. Getting stuff done in Linux these
days is pretty hard; oh sure, I suppose if you whip off a patch fixing
a typo in a comment or something, someone will just apply it. But if
you want to do something substantial, you have to be willing to invest
a lot of time and effort in shepherding it through the upstreaming
process, which implies you've got to have resources backing that
effort. And there's definitely an in-group. Meanwhile, the BSDs seem a
lot more accepting; maybe that's just me. At least FreeBSD and
DragonFly appear that way. Anyway, it seems fair to say that Linux
seems mostly beholden to the interests of big companies these days.
This matches my experience: Lots of gatekeepers, any one of which can take a disliking to your submission for what, at times, seems like arbitrary and capricious reasons. If you make it to the 'in crowd' it becomes more of a rubber stamp at times... I have recently been successful at submitting an obvious fix to a tiny backwater area of the kernel without undue stress though... But I submitted it to the maintainer of the area, who then submitted it to the 'greater maintainer', and then to the greater maintainer and then to the tree. So my tiny fix has more Signed-off-by: lines than lines of change and took about two weeks to make its way all the way up into the repo... For me, it took about 2x as long to prep and send the change than it does for the direct commit access I have for FreeBSD, but I've spent more than 10x on other submissions that ultimately didn't make it in. This is in contrast to the few changes I got in in the 90s: I sent an email to Ralf, who nit picked one or two things, which I fixed and it wound up in his next batch of changes to Linus and made its way in (to code that's sense been deleted, alas).
The BSD are more accepting, in general, though it can be hard to find the right person to approve your change. There's too many ingest points still, too many things fall on the floor, etc. Part of that is tooling, part of it is culture, part of it is lack of clear docs, etc. It is generally easier to get a change into the BSDs. It takes less persistance, on the average, but it still takes more effort than it should.
I looked into Linux's processes to improve FreeBSD's. And came to the conclusion that in large part they succeed despite their processes, not because of them. They have too much overhead, rely too much on magic bots that are hard to replicate and I'm astonished that things work as well as they do. It's a grown culture / process that relies on old tools mixed with new in weird ways you'd never think of standing up today. Things can be learned from it, but it seems to be a unique snowflake relative to all the other projects I looked at...
Warner