Slashdot Mirror
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."
Basically, they only allow developers who are willing to sit through a 30-minute video to work on their software.
I am the richest astronaut ever to win the superbowl.
but at least he is stubbornly consistent. Without it, openBSD would not exist in its current fine form.
That video can serve as a lesson to others on how to manage a project for an extended period of time and keep things consistent and predictable.
Feed the need: Digitaladdiction.net
The slides are here: http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/
MS-DOS: zero remote holes in the default install.
HermesPod: Free Podcast Download Manager for Windows
What I got out of it was that the core developers, not some other group, do the testing. Rather than hand the task of quality control/testing to some other group just prior to release, all developers are held to a high level of participation in this regard. Theo and other developers use nightly builds in their day-to-day work and the entire system compiles most every night.
That was a William Shatner video.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
Two points:
1) they do not create a separate branch for a release. The release stays in TRUNK until it is released. This has the advantage that ALL developers are working towards a release. Introduction of features is slowed as a release approaches. He does not address the disadvantage of this system: that many developers sit around idle when their work is completed early during this phase.
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.
Point 1) was interesting. It works for them because they are volunteer based. They are not paying the salaries of the idle developers during the release phase. It would not work in a corporate environment because those people are to valuable to be underutilized.
NOTE: I did not listen to him talk... just read his slides.
No wacky and nutty GPL kooks.
No screaming diatribes over 'purity' of ideology.
No foaming at the mouth tantrums that someone is using your code and not kissing your fat ugly ass in reverence.
Over the years I've learned that BSD developers are engineers while GPL developers are ideologues - ie. wackos and nutcases.
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.
Every BSD project I've followed or participated with has been a positive experience due to those types of licensed projects attracting engineers who just want to write good code and want their code to be available and free to everyone to make good use of it.
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.
#fuckbeta #iamslashdot #dicemustdie
Not that that would be a bad thing. The majority of people in the world are average, by definition. When a truly extraordinary person tells them what to do, and they shut up and do it, the collective ability of the group is far greater than the mere sum of its parts. If the extraordinary person happens to be a bit of a knob, that's irrelevant if they are all focused on the desired result and not their own silly little egos.
"Oh noes, he told me my code was stupid and wants me to to it again! Cry cry cry!"
If Theo tells you your code is stupid, then it is. End of story. Do it again. Yes, there are better ways to deal with people, but seriously, Theo gets knocked for his personality not because it's really that big a deal, but more because ordinary people are jealous of his enormous capacity.
Get over it people. Theo's good at what he does, OpenBSD could and would not exist without him, and the world is a better place for it.
I hate printers.
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).
:-) Kudos to them for having the discipline to make it work.
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.
I hate it when I make a joke and I get modded "+5 insightful". Mod the stupid comments "funny", not "insightful", pleas
Long story short: Theo rules with an iron fist and springs releases like pop quizzes.
How we know is more important than what we know.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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.
If you mod me down, I will become more powerful than you can imagine....
No, but assuming you can operationalize 'intelligence', it's a testable hypothesis. And it's always better to explicitly and not implicitly assume. Otherwise people think you're hiding something, 644bd346996 -- if that is even your real name.
.sig withheld by request
How exactly does GCC "lock in" anyone into using "GNU tech"? How exactly is GCC "not truly free"? The only way in which GCC limits you in licensing your code is that you can't build your own shiny new proprietary compiler on top of GCC, and that is a good thing. The "document format" in question here is C. GNU is not claiming ownership of C.
And yes, LLVM is nice, for many thing. By the same toke, it's no panacea, either.
Ezekiel 23:20
OpenBSD is as useless as a bag of rocks
**hits anonymous cowardon the head with a bag of rocks
**thinks that was actually pretty useful.
.sig withheld by request
The problem with your statement is that you assume that Theo is perfect. If he's not (and he's definitely not, just like all of us), then "shut up and do what I say, and I don't need you trying to explain me why I'm wrong, cause I'm never wrong!" mentality will lead to a disaster when he gets something wrong. You could say that it's alright so long as, on average, he's right more often than he's wrong; however, the real problem with mistake combined with arrogance is that mistakes often tend to become grave in such circumstances. It's the "fuhrer problem" - it's very tempting to put a brilliant guy in complete control with no backup, but it only works for limited time in practice.
Theo's good at what he does, OpenBSD could and would not exist without him, and the world is a better place for it.
Who knows; perhaps, if OpenBSD didn't exist, NetBSD would be better?
I could be wrong, but I think the primary reason they release so fast is because the OpenBSD team does not attempt to bundle all of existing open source software with their OS like say Debian is trying to do. In *BSD distros, there is the core OS that includes essentially only the operating system and some utilities, and then there is the ports collection. I believe a serious bug in some port package will not halt the release process of a BSD distribution, at least for non-essential ports.
It would be pointless to test prior to integration of all submitted components.
Stay away, stay faaaaaaar away from my code and applications.
In an ideal world, I suppose, 386BSD would have been managed better and there would be no forks.
In your "ideal world" I suspect we would all be rather less well off.
I've never understood the appeal of one-size-fits all. Why is it the premise of so many off-the-cuff comments in every venue of discussion?
So far as I can see, it accomplishes two things: makes it easy to criticize others for not getting along, and relieves the commentator of having to learn or understand systems theory, which is subtle and difficult. If only the whales had not split off from the carnivorous ungulates, evolution, in the ideal world, would have accomplished so much more. Put into a real context, the idea barely parses.
Within the prokaryote kingdom, there is a great deal of horizontal gene transfer. Within the BSD clade, there is a great deal of horizontal transfer (of ideas and code) whenever the need arises.
horizontal gene transfer
The most profound fork is probably the GPL from the long-standing conventions of public domain, which the BSD license more nearly mimics.
I don't see much difference between the scope of source code and the scope of human interpersonal relationships. In an ideal world, we would all be better off if either A) all information was private, or B) all information was public. Turns out, some people have information they don't wish to share (for a list of reasons which includes every human motivation) so the GPL lacks universal appeal. Turns out, some people have information which they don't wish other people not to share, so neither does the BSD license have universal appeal.
Having the two license camps puts a crimp on horizontal transfer, but it hasn't caused the world to stop turning. Is it fundamentally a bad thing to implement an idea twice, beginning from two different sets of premises? Only if your goal is world domination. For maximizing insight, diversity rocks.
I could continue, but I'm sure the choir has already figured this out, and the sinners are set in their ways.
At the end of the day, fork has become a term of social derision founded upon a monolithic Garden of Eden which never existed, and wouldn't have been a paradise even if it had.
If the only reason to fork is that two parties can't get along (X, libc are possibilities, but I don't know enough of the story) then forking is a mite unseemly, much like a failed marriage. Do open source communities fork more often than any other walk of life? I suspect not. And no, I'm not counting whiner attrition, where one or two guys copy a code base into their own tree, make a dozen patches, and are never heard from again. Does IBM fork every time a deadbeat is fired or quits?
Many of these projects have accomplished things through volunteer collaboration that twenty years ago few would have believed possible, yet they are mostly criticized in retrospect for the occasional loud public spat prior to a parting of ways, by people who are deeply in touch with their inner primate.
Those of us in the results oriented camp are less inclined to praise the false nirvana of pretending to agree when you really don't.
For an interesting comparison, consider the disputes over the years within NASA over the "smaller, faster, cheaper" engineering meme.
Small Is Beautiful, But Big Is Necessary
I suspect smaller, faster, cheaper might work, but it won't ever be NASA who consistently pulls this off. NASA is what you get when an agency never forks. Ideal leaves a lot to be desired.