Crowding out OpenBSD

The cultural difference is that when a BSD fork happens the tradition says that one subset of the old group gets access to the new fork, lose access to the original tree, and never talk again. When a Linux fork happens the tradition says that the persons who forked still have the same access to the original tree that they had before and, if they want to, can submit patches to the original tree.

Today you have RHEL kernels which are loosely based on Fedora kernels which are based on Linus kernels, more or less. But you also have Ubuntu kernels based on Debian kernels based on Linus kernels, more or less. The kernel teams for each distribution, except RH, are likely smaller than the kernel team for OpenBSD, but the forks are *very small* because tradition says we put upstream as much as we can, whatever can be agreed on, even if it takes a lot of pain for many years. Imagine if the people working on grsec or realtime had to write all the drivers, schedulers, and filesystems instead of just rebasing against a common core; the difference in effort required is enormous.

If the BSDs had operated this way they'd still have a "main" core being fed by a half dozen sub-projects, even if the sub-project differences were quite large, just as Linux has the realtime fork, distro forks, etc. Now that we have git, which seems to have been designed to facilitate a process that the BSD folks don't remotely follow, the whole "many forks, one core" approach works even better and the pace of the fork-experiment-pullrequest-reject-hack-pullrequest-merge loop has gotten faster.