This is going to be a hard story to tell, because on one hand I don’t want it to become a selective memory autobiography, but on the other hand, I was one of the most central persons, for some years probably the most central person in the FreeBSD project, and there are parts of the story only I can tell.
That is not to say that there won’t be different sides of those stories, there will, and there should, because the FreeBSD project is larger than any one person, a lesson a number of persons didn’t understood when it mattered.
Until I get stranded on a remote desert island with an internet connection that miraculously only allows me to update this page, a very short summary will have to make do.
When 386BSD came out in 1992, I worked as sysadm for the central campus of the FLS group, Denmarks largest engineering company, specializing in building cement factories. I was part of the UNIX/Network/CAD support function, and most of the UNIX stuff was my problem, but random other projects, such as telecoms, also landed on my desk.
Using UUCP I downloaded the 386BSD floppies and suddenly my life and my job got a lot easier.
Amasing as it may sound, I put 386BSD into production almost immediately, to capture a serial data stream from a telephone exchange, so that the data could be used for accounting purposes.
Bill Jolitz worked together with nobody, as far as I can see he still doesn’t, and his version of events is not exactly restricted by verifiable facts, and as a result Rod Grimes and Jordan Hubbard started “the patchkit”, a collection of much needed patches to 386BSD.
My first entry is patch p00019:
Subject: CLEAN UP SLIP INTERFACE TO KEEP FROM HANGING
Here is a patch to clean up the interface between the tty-drivers, in particular the com driver, and the sl# interfaces, this is not a work-around but a genuine bug-fix.
Symptoms: after a number of “com#: silo overflow” SLIP ceases to work.
Overview of the problem: the slip interface will disregard any notice from the tty-driver on problems (parity errors, framing errors or overruns), which basicly means the one might as well throw the packet away right away. Also overrun in the packetizing will go relatively unnotized.
It is probably pretty obvious what I were also using 386BSD for at that point: At my instigation FLS Data upgraded the UUCP connection to DKnet to a 2-wire leased line with “always-up” configured Telebit Trailblazer 2500 modems.
Pretty soon the patchkit got unwieldy, and Bill Jollitz showed no signs of wanting to cooperate, and the FreeBSD and NetBSD projects where created, more or less while I slept. When it came to pick sides I found NetBSD filled with academics and FreeBSD filled with real-life sysadms, and I threw my lot with the latter.
In 1994 I went to USA to work for TRW Financial Systems, which delivered turnkey document-imaging systems to financial companies, on the recommendation of Julian Elischer.
The contract had me in Oakland during development and after delivery to Denmark as the senior on-site engineer for a “giro” processing system for the danish GiroBank.
Pretty soon after landing in the SF Bay area, I was inducted into the FreeBSD Core team, and spent almost all my spare time on FreeBSD for more than the next decade.
From 1994 and forward I made my living partially and from 1997 fully by using and developing FreeBSD.
Since my skill-set was non-typical, I ended up doing non-typical stuff, from running an ISP, cybercity.dk, almost entirely on FreeBSD, to custom solutions of odd-ball problems in Air Traffic Control, and some stuff I still cannot talk about.
Along the way I also snatched a corner of the DARPA “CHATS” programme, and did a kickstarter project for years before kickstarter was founded.
Eventually the “append-only” model of core-team composition broke down, and in 2000 I more or less forced the FreeBSD project to discharge the close to 20 person coreteam, of which only about 5 could be expected to participate actively, Peter, Jordan, Polstra, Søren and me.
It increasingly fell to me do do the nasty jobs, including the forceful retirement of both people and source-code.
Since I usually did so with the moral backing of Søren “sos” Schmidt, my fellow Dane om the FreeBSD core team, my execution of these events gave rise to a running joke about danish/viking axes and the perils of getting too close to same.
We managed to push through some very minimal bylaws, which basically sees the FreeBSD committers elect a 9 person core team every two years, and while not perfect, it seems to work a lot better than the autocratic “core.0”.
In Denmark we have a saying that “The Gnome moves along with you”, it’s kind of hard to explain, but the idea is that if you want things to change, you have to change yourself first. Recognizing that I had become a defacto ruler in the project, through sheer hacking effort, and that it would be very hard for the new core team to function if “The Gnome moved along” I decided not to run for a seat on the new core team for at least ten years.
I also promised myself that I would not comment or critize new-core’s actions in public, but rather take it up with individual core members privately, or in severe cases directly with core. That proved to be harder than I expected, but I mostly managed.
I kept on hacking FreeBSD until I got distracted by the Varnish Project and from approx 2007, I started to let go of FreeBSD.
It took several years before another committer managed to top my commit stats to the kernel, and even now in 2012, five years later, I’m still number two on the list:
I’m not done with FreeBSD, I still run Current on my laptop, and various other FreeBSD versions on my other computers, because FreeBSD is still the best damn UNIX around.
I keep my commitbit warm with the occational bug-fix or update to some of “my” code in FreeBSD, but I’m not spending my every wake hour thinking about how to make it better anymore.
On average, I made a commit to FreeBSD every 18 hours for a decade, some of them were trivial, and a few of them changed the way we think about UNIX and computers.
The book “1066 and all that” teaches us that history is only what you can remember, if you cannot remember it, it clearly wasn’t memorable, and therefore not important. Using that guideline, the important stuff I did in FreeBSD must have been:
The rest was obviously not memorable enough.
In summary: I have spent close to 20% of my expected lifespan on FreeBSD, and I think it was worth it.