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: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.