Contributed by mtu on Sun May 22 08:31:19 2011 (GMT)
from the bigmem dept.
How leaders, managers, mentors and coaches motivate others towards a
common goal is a very well researched topic. The methods typically
used within entirely volunteer organizations center around exceedingly
polite interactions, strong encouragement through accolades, and fairly
gentle suggestions when mistakes are made. The way the OpenBSD project
operates is vastly different from the accepted norms.
Read on to find out more about beck@ and learn why the OpenBSD project succeeds with their goals where others flounder:
[c2k10] Article Series:
(more to follow)
Bob Beck (beck@) is a developer who leads by example and codes the code, so to speak. He started using OpenBSD in 1995 with the first release. He's truly one of the real OpenBSD veterans. At that time, your choice was limited and he was working on networking and needed an OS with networking that really worked. OpenBSD was it.
After Bob settled on OpenBSD, he tried to send Theo a pizza to show
appreciation, but couldn't do it for some reason, so he called Theo
about not being able to send hacker fuel. That was the start of their
friendship, and sending pizza has been a running joke ever since.
"We improve OpenBSD for us, not for others," said Bob, "We're not as
altruistic as you might think." If you've been around long enough,
you have seen this opinion repeatedly voiced, so you may wonder why
the developers continuously improve OpenBSD? --The common answer is,
There are other unique aspects that set OpenBSD developers aside from the people working on other projects. They require high quality and voice their opinions very directly. A person needs to have the right mind set, right skill set, and a personal connection. Bob said, "Software quality wouldn't be the same if we were nice to everyone." Developers must be able to take criticism. Long before anyone gets a cvs account, there is the process of submitting diffs and getting criticism.
A person with the right mind set, skill set and personal connection will
try to improve from the criticism. Keeping people involved and software
quality are often at odds with each other. Many projects try to be too
inclusive and overly nice to everyone. In OpenBSD, the code must stand
on its own merits.
The hackathons are another unique aspect of OpenBSD. I've written a lot about them and how important they are. However, you may enjoy the following insights from beck@:
- You start major design discussions at hackathons (this is an OpenBSD thing).
- Things are either started or finished at hackathons, but almost never both.
- You get dedicated time to concentrate on what you're starting or finishing.
- The other people you need are there to keep you engaged and to tell you when you're wrong.
- You also learn to back out stuff until it is right. This is easier said than done as people become vested in the code they've written and needing to back it out becomes more painful for everyone.
The OpenBSD community has a reputation of being very blunt and direct. They don't sugar coat anything or worry about hurting anyone's feelings. They don't have time or patience for such niceties. Outsiders or people new to OpenBSD often get the wrong impression with OpenBSD's no nonsense approach to communication. The developers know, respect and have a bond of understanding to facilitate very fast and direct communication.
Here's what beck@ had to say about c2k10:
What I did at c2k10: (hacking wise, as opposed to organising, cat
herding, and food aquiring...)
As I mentioned hackathons are places for starting or finishing things.
I started two major things that are now nearing good stuff:
1) I rewrote the NFS server side attribute cache to use a RedBlack
tree and timeouts on the requests. So far I want to tune this a little
more but this is looking promising on my NFS servers. A version of
this or something based on it is likely to be committed post 4.8 -
Basically this is to address a problem we have running UDP NFS on
servers where replies missed by clients cause errors. A cache that is
both larger but more intelligently implemented than the current one
will resolve these issues that I've been able to hit torturing NFS
servers at home.
2) Along with Art and Owain who worked on some of the other pieces, I
spent most of my time working on splitting the buffer cache into two
LRU queues for buffers, tracking both buffers that are DMA reachable
on a machine (using the new UVM pmemrange code) and elsewhere - the
goal here is to allow pages to be flipped into "high" memory when only
being read from, but allocated initially in DMA reachable regions, and
moved into DMA reachable regions if IO is needed to be done from them. In the process, I tracked down a number of bugs. By the end of the hackathon, I successfully had an 8 GB AMD64 running with bigmem using 6 GB of buffer cache. My work still has some
bugs I'm working out (with lower memory machines) but I'm confident
I'll be able to get that sorted out relatively soon.
Bob said hacking on file systems is a nightmare. If you break it,
everyone notices and you hear about it. Changes must be carefully
designed, planned and tested, with the implementation being done
incrementally to always keep everything running correctly. The improvements currently being made on the file systems are very
interesting and innovative. The multistage development process started during c2k10 with the design and planning bits being completed and first steps towards implementation
being committed. When the time comes, we'll do an undeadly article
specifically on file system improvements.
I would like to thank beck@ once again for hosting the general hackathon
every year in addition to all of his coding. His efforts organizing the
general hackathon enable the developers to get together at least once a
year to have fun improving OpenBSD, so he is one of the main reasons the
project keeps moving forward. Of course, your donations and financial
assistance make the hackathons possible. Thank you for your continued
Mark T. Uemura