The BSDs do have comparatively miserable contributor experiences, though I understand why. At least from my very, very limited exposure.

Several years ago now, I ran into a problem with playing audio on NetBSD/sparc. I had an RDI PowerLite laptop, which is 80% of a SPARCstation 5 clone stuffed into a laptop chassis. Part of the 20% different was the audio chip, which was the same AMD ISDN chip used in the SPARCstation 1/2, doing mu-law audio.

Whenever I'd play audio, the laptop would instantly reset. Huh. That's weird. I ended up figuring out that someone had recently massively overhauled the audio driver subsystem in the kernel, and basically the relevant audio driver was missing some mutex operation, and an assert() was panic'ing the kernel.

For a non SMP system, the lock wasn't necessary (IIRC) but the new code was being more rigorous and causing a kernel panic.

The patch was pretty easy, just adding a few locks/unlocks. But I could never figure out what I was supposed to do with the patch after.

I'm probably just stupid. I don't want to imply there's no path to do this, I just never figured it out. I didn't try for long either, since getting 8-bit mu law audio working was just something goofy I was doing for fun.

But for comparison, when I found a bug in the signal handler for 32-bit PowerPC, my memory was that it was pretty straightforward to produce a patch: find the relevant maintainer, open a dialogue, and eventually submit a patch: https://marc.info/?l=linuxppc-embedded&m=160963760120837

Neither fix was ultimately very important, and neither would have impacted more than a couple dozen people on the entire planet. But Linux got a patch, while NetBSD didn't...