> I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos. I'm a form

> I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos. I'm a former NetBSD developer, I left when I got fed up to re-invent the wheel. I spent many years after that supporting a commercial special purpose FreeBSD-basde distribution, and I got a fair share of conflicts on mailing list again "the old guard" (Warner & co) over various subsystem, and had to go as far as calling off an incompetent kernel committer working for Intel at the time. All my grief from ~10 years ago is publicly available in the mailing-list archives. > FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI. IIRC, it is mostly vestigial, unless it has been going though a major updates in the past 10 years. > That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch. Branch lifetime is irrelevant. Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later. > Sure. But you can implement a patch and advocate for it against the existing implementation? Unless you are a committer, the chance of getting ANY significant patch in is pretty much nil. As I mentioned previously, mailing list are NOT for discussing any significant changes, this is done behind the scene in private by a de-facto pseudo-"committee". The development process is closed to a few elites, generally small group of committers ruling over code sections. By the time any patch is ready, its author drops a +5000,-5000 lines turd^Wdiff that is utterly impossible to review. For lack of a better word, BSD are not remotely close to being open to outsiders. I know this by experience.