Last Monday closed on the certified branch of the family and pointed here, to the same lineage without the paper. If the certified Unixes are a register of strangers who happen to share a word, the BSDs are the opposite problem, and the more interesting one: a family that forked as sharply as any, more than once out of a plain falling-out, and stayed a single thing.
That is the fact worth explaining. Fragmentation is supposed to be what forking produces. The Linux world is the standing example, one kernel underneath several hundred distributions that agree on very little above it. The BSDs forked too, and did not fragment. Four siblings came out of one Berkeley source, each with a temperament sharp enough to have caused the split, and each is a complete operating system you can name, run, and hold responsible. The question is why the same act, forking, breaks one family into parts and leaves the other whole.
One Tree, Four Temperaments
Start with the four, because they are genuinely four characters and not four logos.
FreeBSD is the generalist, and the one built to be depended on. Its temperament is breadth held to a production standard: it wants to be the system you put under a database, a file server, a firewall or a fleet of virtual machines and then stop thinking about. The evidence is the quiet kind. Netflix serves a large share of the evening's internet from FreeBSD appliances, every PlayStation runs an operating system that is FreeBSD extended with Sony's own layers on top, and Juniper has routed the world's traffic on it for a quarter of a century. What lets one system cover that much ground is a set of choices the other siblings mostly did not chase: wide hardware and driver support, so it runs well on the machines people actually have; ZFS as a first-class citizen, so storage is snapshotted and self-verifying by default; bhyve, a native hypervisor, for running other systems on top. And jails, the one worth pausing on: kernel-enforced container isolation that shipped in 2000, the same idea the industry would rediscover more than a decade later and call containers, only thinner, enforced by the kernel itself rather than bolted on above it. FreeBSD optimised for being useful to the largest number of people, and the breadth is not an accident. It is the personality.
OpenBSD is the one that would rather be correct than popular. It began in October 1995, when Theo de Raadt, having parted ways with the NetBSD project he had helped found, took the code and started again with a single non-negotiable priority: audit the source by hand, continuously, and ship nothing whose safety cannot be reasoned about.¹ Thirty years later that is still the whole personality. The temperament shows most clearly in what the project gives away. OpenSSH, LibreSSL, doas and OpenNTPD were all written for OpenBSD and now run far outside it, including across the Linux world that does not always remember where they came from; the packet filter pf belongs on that list too, though that story has been told elsewhere.² The project's own boast, two remotely exploitable holes in the default install in a very long time, carries the usual caveats about what counts as default and as remote, and is still not a small thing to be able to say.³ The same discipline draws the limits, too: OpenBSD runs on less hardware than FreeBSD and takes up new drivers slowly, because it will not ship what it has not audited. That narrowness is the bill for the guarantee, not a defect in it. OpenBSD is what happens when a family member decides that doing less, provably, is the ambition.
NetBSD is the one that will run anywhere. Its motto, "of course it runs NetBSD," is a portability claim it has spent three decades earning: the current line targets on the order of sixty hardware platforms across sixteen processor architectures, from modern 64-bit ARM down to machines the rest of the industry has forgotten it ever made.⁴ Portability that wide is a discipline rather than a stunt, because it forces a clean line between the machine-independent core and the machine-specific edges, and a codebase that survives being split that way tends to be a tidy one. NetBSD's other export makes the point twice: pkgsrc, its package system, carries roughly twenty-nine thousand recipes and does not require NetBSD underneath it at all, building the same software the same way on illumos, on macOS, on Linux.⁵ A family member whose package tree is portable to the rest of the family, and well beyond it, is telling you how it thinks. Running everywhere has a price, and NetBSD pays it on purpose: a system that must boot on sixty platforms leads on none of them, chasing neither peak performance nor the newest hardware, because the reach was the point.
DragonFly BSD is the youngest and the most opinionated. In June 2003 Matthew Dillon, a FreeBSD developer, disagreed with the way FreeBSD had chosen to use many processors at once, the fine-grained locking of the coming FreeBSD 5, and rather than argue it release after release he forked FreeBSD 4.8 and built the alternative.⁶ The alternative was a kernel organised around message-passing and lightweight threads instead of locks scattered through the code, and out of it came HAMMER2, a filesystem with snapshots, clustering and self-healing that no other BSD carries. DragonFly is the smallest of the four by users and the largest by distance travelled from the shared starting line, which is the useful thing about it: it is proof that a fork in this family can be a laboratory rather than a schism.
Why It Stays Whole
Four forks, then, and four temperaments sharp enough to explain each split. The question the certified branch could not answer, what actually holds a family together when the paper does not, this branch answers by construction.
What the four share is not a certificate and not a marketing council. It is the shape of the thing each of them inherited: a base system. In a BSD, the kernel and the core userland, the compiler, the C library, the shell, the daemons, the manual pages, are one source tree, grown together, released together, and audited as a single object. Third-party software sits on top of that line, as ports or packages, visibly outside it.
Fork a system built that way and you do not carry off a fragment that needs a hundred other projects before it becomes usable. You carry off a whole, and you keep growing it as a whole. That is why OpenBSD and DragonFly, born from the two sharpest disagreements in the family, are not loose collections of patches but complete systems with their own release engineering and their own character. The coherence is not a rule anyone enforces after the fact. It is simply where the code lives.
It is worth being precise about the contrast with Linux, because it is a difference in design, not a difference in worth. A Linux distribution is assembled: a kernel from one project, a C library from another, core utilities from a third, an init system that occasioned a decade of argument, and several hundred more parts, each independently governed, integrated into a working whole by the distributor. That integration is real engineering, and some of it is superb. But the whole lives in the assembler's hands and has to be remade every release; the coherence is a service the distribution performs, not a property of a single tree. Both answers ship excellent systems. They keep the whole in different places, that is all: a BSD keeps it in the tree, and a distribution keeps it in the work. The one solves coherence once, in the tree; the other solves it again at every release. Forking a tree hands the next maintainer a whole system. Forking a kernel hands them a kernel, and the invitation to assemble everything else again.
The certified Unixes shared a word. The BSDs share a code lineage, and they have spent thirty years demonstrating that the lineage is the more durable thing, precisely because it let them disagree without breaking. They forked over security, over portability, over how to drive a processor, and each fork produced not a splinter but a sibling: a complete system with a temperament of its own, still readable, in effect line by line, back to the same Berkeley source.
The Point
Code lineage without the paper turns out to be the most alive branch of the whole family, and the reason is unglamorous. When the whole is kept in one tree, a disagreement can take the tree and remain whole. When the whole is kept in the assembly, a disagreement takes a part. The certified branch shares a certificate and stays strangers; the BSD branch shares a source tree and stays kin, through the sharpest disagreements a project can have. A shared lineage holds where a shared word could not.
Next Monday: discipline without descent, the outsider that kept the rules Unix wrote, in a kernel Unix never chose.