OpenBSD: Maintaining the quality mindset

Come October, Theo de Raadt will be joined by five fellow developers for an intense period of takeout food, hikes through the hills in his native Calgary, Canada, beers and long conversations about the future of OpenBSD, the open source operating system for which de Raadt is project head.

Come October, Theo de Raadt will be joined by five fellow developers for an intense period of takeout food, hikes through the hills in his native Calgary, Canada, beers and long conversations about the future of OpenBSD, the open source operating system for which de Raadt is project head.

At the same time, they'll co-ordinate the final touches of the next release of OpenBSD, which will emerge on November 1 as the latest iteration of a carefully structured design process that's resulted in a new release every six months for the past 10 years.

The last two months of that six-month cycle reflect the care with which de Raadt and his dozen-strong team of core developers has looked after the OpenBSD source. After four months of intense and frenzied development, OpenBSD's APIs were locked down this week; the rest of the code will be intensively tested and progressively locked down until developers can do no more than make simple edits to MAN pages.

In late October, the entire code base will be frozen and the master CD release for pressing. On November 1, once the disc is out the door, the code will be unlocked and a new frenzy of development will commence as members of the environment's extended global development network gear up again for the May 1, 2005 release.

Such is life at the helm of OpenBSD, a lower-profile open source cousin to Linux that has matured considerably from its roots at the University of California, Berkeley. Yet while grassroots support of Linux has enjoyed strong brand recognition and the endorsement of governments, companies and major IT vendors alike, OpenBSD continues evolving in relative obscurity - so much so that a recent book on the environment named just 220 known users, even though one reseller de Raadt has spoken with has installed 11,000 OpenBSD servers in the last four years.

de Raadt's explanation for this curious mismatch: many customers are simply using OpenBSD in quiet mode, choosing it over alternative operating systems in a recognition of the meticulous coding and exacting standards that de Raadt and his team demand.

"We are non-stop trying to find ways across our entire source tree that small little programmer errors result in problems," says de Raadt, who fronted the AUUG 2004 conference in Melbourne this week to share his experiences. "The problem with security is that people learn what they're supposed to by example, learn they're supposed to use APIs in a certain way, and they're just wrong. At some point, we have to start asking ourselves whether features are the thing, or whether quality is the issue. I really think we have to focus on the quality before the features".

The key difference between OpenBSD's design and that of Linux, says de Raadt, is that Linux is effectively an assemblage of individual development efforts centred around a single Linux kernel controlled by Linus Torvalds. OpenBSD, on the other hand, is a complete operating system that is built from a single, carefully managed code base and tested end to end before each release.

With a concerted focus on security, the OpenBSD effort has spawned open tools such as the OpenSSH toolkit, which has become the de facto standard for secure online communications in many Unix and Linux distributions. Other byproducts of the effort include a robust BGP implementation, IPSec stack and packet filter.

Far from resenting the widespread borrowing of the group's security, de Raadt encourages it: "We are software security craftsmen," he smiles. "I'd rather have people there using our software than writing their own and doing a bad job of it. If their machines get broken into, everybody else's insecurity on the global Internet becomes my insecurity".

In the OpenBSD world, after all, there is no pressure from marketing organisations to push new features to meet arbitrary deadlines. Once submitted by developers, new features are carefully tested, revised and reworked until it's bug-free; if a feature isn't ready, it simply won't ship until the next release. Or the next one.

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All