DragonFly BSD Forks From FreeBSD 4.8 Over SMP Design Disagreements

In June 2003, FreeBSD developer Matt Dillon began work on what would become DragonFly BSD, announcing it publicly on the FreeBSD mailing lists on July 16, 2003. The fork wasn’t a dispute over licensing, governance, or a company acquisition — it was a technical disagreement about the right way to build symmetric multiprocessing support into a BSD kernel, and it split off an entire independent operating system project as a result.

What FreeBSD 5 was doing differently

FreeBSD 5.x was in the middle of a major SMP architecture overhaul, moving away from the older “Giant lock” model (where a single kernel-wide lock serialized most kernel execution across CPUs) toward fine-grained locking, where individual kernel subsystems each get their own locks, allowing genuinely parallel execution across multiple CPU cores instead of one process running in the kernel at a time regardless of how many cores were physically present.

Dillon believed this specific approach — the fine-grained locking model FreeBSD 5 was adopting — would lead to long-term performance and maintenance problems. His alternative vision centered on a different mechanism entirely: lightweight kernel threads (LWKT) combined with an in-kernel message-passing system, an architecture closer in spirit to some ideas from message-passing operating system research than to the fine-grained-lock approach FreeBSD’s own developers were converging on.

From technical disagreement to a full fork

Dillon’s ability to directly commit his preferred changes to FreeBSD’s own codebase was eventually revoked following conflicts with other FreeBSD developers over how to implement these ideas — a disagreement serious enough, and fundamental enough to the kernel’s core architecture, that reconciling the two approaches within a single shared codebase wasn’t a realistic path forward. Rather than abandon the approach or continue arguing for it inside FreeBSD’s own development process, Dillon forked FreeBSD 4.8 specifically — the last release before FreeBSD 5’s SMP rework — as DragonFly BSD’s starting point, positioning the new project as what he considered the more sound continuation of the FreeBSD 4.x line’s architecture, developed independently going forward.

What DragonFly BSD became

Over the two decades since, DragonFly diverged substantially from its FreeBSD 4.8 starting point rather than remaining a close derivative. Its LWKT and in-kernel message-passing systems became foundational to the project’s own kernel architecture, and DragonFly later developed HAMMER (and its successor HAMMER2), a filesystem built specifically around DragonFly’s own design goals rather than adopting UFS or ZFS as its primary filesystem the way FreeBSD did.

Despite the split originating in a genuine architectural disagreement, the two projects didn’t become adversarial — DragonFly BSD and FreeBSD have continued to share bug fixes, driver updates, and other improvements across the two decades since the fork, reflecting that the disagreement was specifically about one architectural approach to SMP, not a broader rejection of FreeBSD’s direction as a whole.

Why this history still matters

The DragonFly fork is a useful, concrete example of something that comes up repeatedly in open-source operating system history: a technical disagreement, when it’s fundamental enough to a kernel’s core execution model, is sometimes genuinely not resolvable by continued discussion within one shared codebase, and a fork isn’t necessarily a sign of project dysfunction — sometimes it’s the only way for a fundamentally different technical vision to actually get built and evaluated on its own terms, rather than being permanently deferred inside a project that’s already committed to a different direction.

Sources: