ocifbsd did not descend from the clouds fully formed. Nothing worth using ever does. It was built the way real software is always built — through a great many small, deliberate commits, each one fixing a single thing or adding a single capability, stacked patiently on top of each other over months, until one day there was a working runtime where before there had only been an idea and a hunch. Three months. Three hundred and ninety-five commits. Roughly a quarter-million lines of C. The repository is the honest record of all of it, and I’d gently suggest you read it as a story rather than a changelog. It reads better that way.
A quarter-million lines, and why they’re in C
Let’s address the language question up front, because someone always asks. The runtime is written in C — not out of nostalgia, not to prove a point, but because C is the right altitude for a tool whose entire job is to speak fluently and directly to the FreeBSD kernel. Jails, VNET, RACCT, pf, devfs — these are the primitives ocifbsd drives, and they’re happiest when you talk to them in their own language, without a tall stack of abstractions muffling the conversation. When your whole purpose is to be the thin, sharp layer between a container and the kernel, you want to stand as close to that kernel as you reasonably can.
The tree spans a satisfying range of subsystems: image handling, an OCI-to-jail translation layer, a networking configuration model, a registry client, an orchestration state machine, a logging daemon, a security daemon, and the user-facing command surface that ties it all together. And here’s the design instinct I most admire in it — each of those subsystems is small enough that one person can hold it in their head, and they’re wired to each other through narrow, legible interfaces rather than a tangle of shared everything. Small pieces, clearly joined. It’s the difference between a machine you can service and a machine you can only replace.
The features you can point at
Some commits are landmarks — the ones where you can point at the history and say, “there, that’s the day the tool could do a new thing.” build arrived, and suddenly the platform could assemble its own images from a Containerfile. stats arrived to report per-container resource usage as JSON — and that very feed is what powers the live dashboard on this site, the numbers you can go watch move right now. proxy arrived as a native layer-4 load balancer, then kept growing: load-balancing algorithms, sticky sessions, correct half-close handling, a pre-forked multi-worker accept pool. And networking got a whole run of fixes that transformed VNET from “attached to the bridge but completely mute” into containers that actually route packets like grown-ups. The lovely thing is you can trace every one of these as a clean sequence of commits, each with a message that says plainly what changed and, more importantly, why.
The unglamorous discipline that holds it all up
But here’s the part that never makes it onto a feature list, the work nobody throws a launch party for — and it’s the part I want to end on, because it’s what actually makes the rest trustworthy. Indentation was converted to hard tabs to match FreeBSD’s style(9). Trailing whitespace was stripped across the entire tree. Ignored return values were explicitly marked as intentional, so the next reader knows it was a choice and not an oversight. A clunky fork+ifconfig was replaced with a direct if_nametoindex(3) call. Quadratic string-building was rewritten to run in linear time using open_memstream.
None of that changes what the software does. Not one bit of it shows up in a demo. But all of it changes whether the next person — possibly you, possibly future-me at 2 a.m. — can safely reach into the code and change it without holding their breath. Three months of that quiet, repetitive, unglamorous discipline is the real reason the interesting features could be built on solid ground instead of on sand. The flashy commits get the applause; the housekeeping is what keeps the building standing.