Why OpenBSD's Release Process Works

An anonymous reader writes "Twelve years ago OpenBSD developers started engineering a release process that has resulted in quality software being delivered on a consistent 6 month schedule — 25 times in a row, exactly on the date promised, and with no critical bugs. This on-time delivery process is very different from how corporations manage their product releases and much more in tune with how volunteer driven communities are supposed to function. Theo de Raadt explains in this presentation how the OpenBSD release process is managed (video) and why it has been such a success."

Comments

It works?

[girlintraining]

Let's compare --

Linux (1991--present): The code base has never forked. The release process has remained largely in the hands of Alan Cox and Linus Torvalds throughout its history, and except for some cosmetic differences, patch submission and integration has been handled the same way. Most people consider the two head developers and various major contributors to be, on the whole, pretty nice guys, though the snafu with loading binary blobs, and the driver architecture supporting 'non-free' elements in kernel-space was notable for the high level of frustration on all sides.

OpenBSD (1994--present): Forked from NetBSD (1993--present), who forked from 386BSD (1992--1994), that originally derived its codebase from BSD4 (1977--1995). The history of BSD is a blood-bath of politics leading to forks; Most of the developers of the *BSDs are variously referred to as "difficult, abrasive, etc.," although Theo, to his credit, has had a major change in reputation over the past several years.

Historically, the BSD variants have enjoyed a smaller uptake in the market and casual open source contributors find it difficult to get involved because of cultural/political differences. They also tend to fragment, as noted by the number of variants, which further weakens their position. Linux, on the other hand, likely enjoys a much broader userbase and more contributions due to its more relaxed community standards and the general approachability of its core team. I would say the "release process works", but by feature count, contributions, and hardware support, the process is full of fail. Does that mean it's a failed project? No--I'm just saying that the differing priorities and political/cultural values held by the core developers has had an overwhelming impact. Businesses might appreciate the consistency of the release schedule and the relatively bug-free nature of those releases, but looking at market share it's pretty clear those are not the priorities for most businesses.

Re:It works?

[Anonymous Coward]

Alan Cox hasn't really been an important figure in Linux for like 10 years.

Sometimes I think most of the people on this site got laid off after the dotcom boom and are just mindlessly repeating a view of the IT world circa 2001.

Re:It works?

[grub]

Another schism was when de Raadt was booted from the NetBSD team and formed OpenBSD back in the mid '90s.

In hindsight, that was probably one of the best things to have ever happened in Free-OS-Land. I sure am happy it did.

.

Re:It works?

[SavTM]

Sir, a full exploration of all of the facts and an exhaustive comparison between all the Unix variants has been the subject of many books, panel discussions, conventions, and academic discourses, and has yet to be fully explored. I think that a high-level overview is both more productive, and better suited, for a humble posting on an electronic forum.

Actually, there is a dichotomy between OpenBSD and all other operating systems. Theo's political stances have brought a lot of problems for the development of OpenBSD as compared to other BSD dstributions, but at their core, the OpenBSD devs are concerned with server security, open code and open protocols and not necessarily the latest features. This process is called security auditing.

They still have only a generally limited window manager, but without the plodding devotion of the OpenBSD team, many binary WiFi blobs (that have been reverse engineered by the OpenBSD team) would still be enabling security breaches while legitimate users were none the wiser. SSH, and the use of remote terminals for all operating systems, have been vastly improved because of the OpenBSD project and it's (simple) minimum requirements which are generally unmet by the commercial software industry.

Whether or not the OpenBSD platform ever grows into a popular client for web-browsing and document editing, it seems as if the community of developers using OpenBSD for their work have definitely succeeded as administrators over the years. And because of the license BSD provides to developers, all of the code in OpenBSD can be used in other projects, whether or not those other projects meet the political standards of Theo de Raadt.

Re:Summary?

[darthwader]

To translate to the "agile" buzwords of the day, they use a 2 week sprint cycle, and at the end of each sprint, the features for that sprint are complete and working, and the product is stable. They ensure this by doing daily builds and testing on those builds. Everyone runs the current build (he implies they run the daily build, but I expect that is too much hassle to upgrade every day, so in fact everyone runs the last sprint build (which is less than 2 weeks old, and has had a brief stabalizaiton period).

It's not rocket science, the notion of small "sprints" and a releasable product ready at the end of each sprint is fairly well known. All it requires is more discipline than 99% of development teams have. :-) Kudos to them for having the discipline to make it work.

god i hate wanky titles.

[timmarhy]

the poster is making the assertion that it works, a lot of people would say their release cycle is a terrible burden on the project.

1. code freeze happens every six months meaning you don't get to finish off features and fixes which might have been of huge benefit. it would make much more sense to base your release cycle around features and improvements, then some arbitary number of days.

2. openBSD EOL's it's releases so quickly, that only in the very rare instance that a business is willing to pay through the nose for inhouse support will you be able to see your system patched.

3. 6 months is way WAY too short of a time for a whole new release. 12 months (if you have to go with the retarded time based release) would be much less of a drain on resources as there is a certain amount of work that must go into a release wether it's got useful upgrades or not.

i've used openbsd in production environment, and it doesn't cut it in hardware support or speed. it's firewall was nice, but i've got that in freebsd now which is a far better OS.

Re:god i hate wanky titles.

[Tom]

I call bullshit on all of that, and I do have a couple OpenBSD systems installed in a commercial setting.

1.) if you wait for the coders to finish up the "cool", uh, sorry "desperately needed" features, you could just as well put the release date on Independence Day, 2025. Having a fixed date forces the coders to concentrate on the essential, instead of the "cool" stuff.

2.) yes, you need to upgrade rapidly. However, your point is misleading. Upgrading OpenBSD has, in all the many upgrades I have made, been no more problematic than, say, running "apt-get update && apt-get upgrade" on Debian.

3.) it's not a "whole new release". It's minor version numbers every six months. And six months can be a damn short time in the security world.

i've used openbsd in production environment, and it doesn't cut it in hardware support or speed.

So you're lamenting why, exactly? If the release cycle isn't even your main problem?

Re:Summary?

[brusk]

That assumes that all developers are roughly equivalent. But if, says, the filesystem is basically in feature lock whereas active development is going on in the networking system, the fs developers are likely to be sitting on their hands. Sure they can test networking features, but that's not their expertise and their time might be much better spent working on the next generation fs, which is not going to be in the next release but might be a couple of releases away. A branch/trunk split would allow them to work on those experimental, too-rough-to-release features. That could make for a more efficient allocation of human resources in some respects.

Re:Summary?

[rbanffy]

If there is a human testing, it's already wrong.

Perhaps developers who feel "idle" (if they exist at all) should be writing automated tests or, at the very least, thinking on how to automate stuff like testing for real-time kernel concurrency problems or device-driver weirdness.

I am a Toro Fecundian

[Mana Mana]

but this is just plain wrong!

`` exactly on the date promised''

Lies! OBSD releases are regularly released a month early.

And, the canard that de Raadt is an asshole is plain wrong. To those who follow OBSD for anything other than a short period of time will know what his, the team's refrain is: We make this OS for us, not for you! Your benefit is an unintended consequence. We don't want to be the most popular, we make this OS for us, not for you! You want Linux. We don't talk, we code. We don't suggest bs features, we code. You want it, code it. But then you keep posting to the list, you've been told to help yourself, that we make this OS for us, not for you! So I will now tell you to fuck off, slacker.

It's simple, man. I've read Bruce Perens say he met the guy, extended his hand but the guy never acknowledged him, that he might be Aspergerish. I thought Bruce was off his rocker when I read that. He bats .400 most of the time, and some-times I say WTF is he drinking today?

Check out theo.c for a lot of laughs!!!

One list goodie went sort of like this years ago: Why are you posting to misc@. Why didn't you read the man pages, slacker. They're quality, this is not Linux. If you didn't bother you're an idler. If you read them and didn't understand them you're a lamer.

"you bring new meaning to the terms slackass. I will have to invent a new term." --Theo de Raadt

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c

Re:Summary?

[aztracker1]

I find that in a corporate lifecycle, having two projects to work on helps.. as one project approaches release, another is just coming out of a release, and into a rapid bugfix push... alternating the primary focus of your development time... This works pretty well actually.

Re:No critical bugs? BS.

[RiotingPacifist]

Even so, it looks better than something like a typical Linux distro (only two remote kernel vulnerabilities in the last six months, plus however many application vulnerabilities you got from all of the extra stuff that's installed by default)

Obviously i agree it will be better, but most distros have ssh disabled by default, so the only count of remote vulnerabilities is kernel

only two remote kernel vulnerabilities in the last six months

No security conscious distros ship with vanilla kernels, typically its an old (2/3 versions 6-9months) secured kernels that has had most vulnerabilities ironed out, obviously some vulnerability come out that affect all recent versions or all 2.6.x versions but generally counting vulns on the vanilla kernel is a very bad measure, tbh thats why i asked i have no idea how much worse a stable distro is (over its supported life, obviously BSD completely owns if you compare unsupported versions)

Re:Summary?

[BitZtream]

2) Everyone tests. There is no test team. All developers test things before a release. He does not talk about agile and how everyone should be testing their own stuff anyways.

They do test their own stuff. They also test how their own stuff works with everyone elses changes rather than in a little sandbox on the side without interaction with all the other parts. This interaction is where you run into problems. Most developers can write small chunks of code that work fine when used exactly as expected, which is what the original developer will do since they know exactly how it was intended to be used. You get in trouble when I start using your code that you documented one way and I interpreted a different way, which you didn't bother to sanitize the input or properly error check, and I just assumed your code was going to work flawlessly. Now, through no fault of yours or mine directly, we've introduced a problem that neither one of us will notice when playing in our own little sandbox.

You point this out like its a bad thing, in reality this is the only way it should be done.

The developers who finish their work early are not sitting idle, they are testing. The sooner the testing gets done and everything is signed off on, the sooner everyone can move forward. It prevents you from just working on what you want to work on and leaving everyone else to do the dirty/unfun work.

Both of your points that you think are bad are just signs of selfishness on your part and a lack of willingness to be a team player. The world doesn't revolve around you or your code, sorry.

Re:No Bearded GNU Freaks Why BSD Is So Good

[kelnos]

This crap is marked insightful? Wow.

No wacky and nutty GPL kooks.

No screaming diatribes over 'purity' of ideology.

You do realise we're discussing an article about Theo de Raadt, right? From what I've read, he's just as much of a BSD kook and idealist as RMS is. Just he gets less flak for it because he (currently, at least) is much more respected for his *engineering* contributions than RMS is.

Over the years I've learned that BSD developers are engineers while GPL developers are ideologues - ie. wackos and nutcases.

Wow, so I'm a wacko and a nutcase, and not real engineer? Sorry, not buying it.

Thank god BSD is well on their way to ridding themselves of GCC and already have the amazing LLVM compiler tech building the system. The efforts the GNU crowd has done to keep open source developers locked into their compiler is sickening from anyone who likes to believe the open source world is some sort of technological marketplace of ideas compared to the Microsoft world.

Yes, because everyone is just so completely *required* to use gcc. You can't use icc, Sun cc, MSVC, or anything else once you've even *touched* gcc. The fact that until recently there hasn't been another good open source compiler around says more to the quality of gcc and the lack of commitment or desire on the part of other potential compiler writers than anything negative about gcc. I'm sure LLVM is great, but apparently no one "needed" it until recently.

Man, too bad my mod points from yesterday didn't expire. -1 Flamebait, Troll, Misinformed-Idiot.`