Date: 2015-10-25

On October 18th 20 years ago the first commits to the OpenBSD project landed in the CVS repository. Today on the anniversary the beastie.pl team invites all readers to a series of interviews that our staff conducted with the project developers.

We continue with our eight interview - Ted Unangst.

1. For the readers who don't know you, can you shortly introduce yourself?

I'm not very good at autobiographies. I've been tedu@openbsd for about 12 years. I work on OpenBSD as a hobby.

2. Why did you choose to run OpenBSD? How long have you been using it?

A friend introduced me to OpenBSD about 15 years ago. At first I was just fooling around with it, and dual booting as necessary, but once I started using it as a server, I didn't want the embarrassment of downtime whenever I had to reboot. Then I figured out I could write papers using WordPerfect (via Linux emulation) and stuck with OpenBSD full time.

3. For those readers that still haven't joined the OpenBSD community, why should they try OpenBSD?

Everybody is looking for something different, so that's hard to answer, but I like the simple approach the project takes. We move a little slower, sometimes, though the phrase we like to use is evolution, not revolution. Every release changes something (hopefully for the better), but it always feels like the same system.

4. Is OpenBSD your daily driver at home & at work?

Absolutely. Actually, I run some other systems as well to change it up, but I sometimes go weeks without touching a system that's not OpenBSD.

5. How did you become an OpenBSD developer? What do you think is required in order to join the OpenBSD project as a developer?

I was fooling around with null and union mounts (a way of overlaying one part of the filesystem on top of another) and encountered some bugs. I tried fixing them with a giant diff (mostly derived from NetBSD) but the other developers weren't too excited about it. I split it up into a few smaller diffs, and also sent some patches for a few other random issues I'd encountered. Or not even issues, just little code cleanups. Eventually I guess it was easier to have me commit the changes myself.

6. Can you tell us about some OpenBSD-related areas you work on?

It's not really restricted to one area. I have an ongoing interest in memory management and filesystems, for example, but also did some work on little tools like grep. Recently I've been (re)writing some security critical tools to be simpler, both from a user perspective and for other developers. And of course, I have lots of opinions on the work others are doing, but I try to only meddle when it's important.

7. Do you have an idea of the time you spend working on the OpenBSD project?

It varies a lot. I only work on OpenBSD when I want to, so it depends mostly on whether there's something I want to work on. There's usually something fun happening, so probably a fair bit of time.

8. OpenBSD tends to lead in development best practices does it work the other way around? Is there a process improvement the project started or aims to adapt from the oustide world?

I don't think we're doing anything that hasn't been done before; just maybe other people don't seem to feel like doing it. I'm solidly convinced that regularly scheduled releases are the best way to ship software, and I've had some success convincing others to do the same. A lot of the time, though, it turns into a scramble to squeeze features in before the deadline. I think OpenBSD is pretty good at slipping features instead of compromising quality.

Moving forward, I think we're learning to deal with long term maintenance of software. Lots of OpenBSD developers have come and gone over the years, but their code always remains. In a project where people only work on things they care about, this can leave some gaps in coverage. Hence the motivation to reduce and simplify code and features, so that in ten years time there is less maintenance necessary.

9. It's been a long 20 years of amazing releases. What are you most proud of and what would you like to revisit/redo?

Personally, I'm pretty happy with the way signify turned out. It was the kind of project where we would inevitably discover problems and shortcomings as we went, and what seemed workable to start would turn into a disaster just a day after we committed to using it. Fortunately, it's worked out pretty well. There's always something that could be better, but it's a good first effort.

There's also the exploit mitigation work done in malloc(). Some of that work has been picked up and found useful by other projects, but I also think there's quite a bit more that we could be doing.

10. As a conclusion, can you tell us how you forecast OpenBSD's future? What's the next big challenge?

As I said before, OpenBSD prefers to move a little slow. This has saved us a lot of wasted effort chasing the latest fad, only to switch directions a year later. At the same time, in order to stay relevant and not fall too far behind, we have to guess what's a passing fad and what's an inevitable change.