OpenBSD Journal

[c2k10] Expectations (Part 3)

Contributed by jcr on from the unmanaged-expectations dept.

(click to see names)
Different people get into OpenBSD in different ways and for different reasons. I can give you my own experiences and opinions, but as such, they will fail to be universal or even be correct for anyone but myself. Unlike most undeadly articles, the following will be light on technical details, but hopefully you will find it useful.

As Theo told me over a decade ago, "The project is code," but my opinion has always been slightly different. I intentionally fail to draw a distinction between the code itself, the people contributing it, the friendships between them, and the fun of coding. In a formal sense I know I'm wrong and Theo is right. The code stands on its own. The greatest diff in the world should be committed on its technical merits alone. The trouble is, without other people willing to look at it, test it and vet the ideas, its technical merit may never be known and it may never make it into the tree. The lone genius programmer working in isolation and doing everything himself is a myth. When contributing in a group setting like OpenBSD, getting improvements committed is much easier when you know both the process and the people.

To understand OpenBSD development and why the hackathons are so important, the first thing you need to realize is the OpenBSD developers really care about building the very best operating system possible. You could call the OpenBSD hackathons amazingly successful just by the cold metric of increased volume of source code commits, but you would be missing the more fundamental reasons why OpenBSD hackathons are so vitally important. The hackathons are a chance for like-minded friends to have fun spending a week concentrating and collaborating on something all of them care about.

[c2k10] Article Series: 1 2 3 (more to follow)

People caring enough to join together in collaborating on a fun and beneficial group project seems painfully simple when stated. It happens all the time. If you look around your home, there will be lots of groups of volunteers banding together to do one good thing or another. Unfortunately, most people view computer systems and software as the cause of endless headaches, the drudgery of a day job, and the product of some faceless company. They simply cannot understand or even imagine others having fun improving software and solving problems with it. Even on the OpenBSD mailing lists you will see this specific lack of understanding from subscribers who really ought to know better. There are people signed up for the lists only because the lists allow them to do their jobs. The idea that others are signed up to those same lists for fun simply never dawns on them.

(click to see names)
When people actually care about something, they tend to have strong opinions. When you are wrong, you hear about it, very directly and in no uncertain terms. Absolutely no one is given special treatment. You have a choice between being offended and leaving, or appreciating the criticism and trying to do better. The people who get offended are the ones who have missed the obvious; another person just gave you their time in writing out their opinion and correction. They may have skipped showering you with sunshine, rainbows and ponies, but how you feel is unimportant. The thing that matters is the thing they care about, the best way to do it. For the unfamiliar and across cultural/language boundaries, this approach can seem very abrupt at first, but if you look at it pragmatically, you'll see it is highly effective and efficient. On a long enough timeline, the survival rate for everyone drops to zero, so time is the limiting factor for everyone. When you view this macabre observation in the context of the very limited free time available for fun hacking, you'll finally understand why communications tend to be very direct and terse.

Once you can handle being wrong and responding by learning from your mistakes, you finally have a chance of being able to really contribute. The amazing skills of the systems programmers contributing to the project were learned through continuous effort. When you only see their successes and skills, it's tough to realize they got things wrong, learned from their mistakes, and kept going. There is no magic, instead, there is only tenacious effort.

OpenBSD is always moving forward, so it always needs your help. You may not be a godly systems programmer able to contribute amazing new code, but you can always still help out by testing code for others. Writing great code consistently is extremely difficult and often takes the efforts of many skilled individuals working together. Thoroughly testing new code can be even more difficult since it can require the efforts of even more people to cover all of the possible uses. Not all testing tasks require an army, but some do, and the effort you put in will be very much appreciated... --even if you do it wrong and are asked to do it again.

If you think you're somehow too good for the dirty job of testing, you are sadly mistaken. All of the OpenBSD developers are constantly testing new code *before* you ever see it committed to the source tree. Code in need of testing and vetting is constantly being passed back and forth between the developers. Unlike other projects, the OpenBSD developers act responsibly. They do the required testing before committing their changes to the tree, so the OpenBSD -current development branch is kept in a usable state as it moves forward.

(click to see names)
Even knowing all of the above and over a decade of working with various project developers, being invited to my first hackathon was a strange mixture of being happy and excited but also wondering if I really had what it takes to make useful contributions? What should I expect? What should I be prepared for? What equipment should I bring? What should I study beforehand? What should I concentrate on? --The list of very typical questions running through my head was endless. Lucky for me, I was invited to the hackathon specifically to do testing. This helped to limit my questions and expectations, but of course, it didn't cover everything. I still wondered about a lot of things but I decided to not worry about it too much, since if they did not want me at their invitation-only event, I would not have been invited.

There's no sense in dodging the difficult question. You're probably wondering how I managed to be involved with the project for a dozen years and worked with a number of the project developers over that time but was still never invited to a hackathon? The honestly blunt answer is, before this year I had never made enough significant contributions to the project to warrant an invitation. It might sound a little harsh, but it is completely true.

First of all, I'm not a systems programmer by any stretch of the imagination and my understanding of the OpenBSD code base and system API/ABI is fairly limited. With enough effort, I probably could have learned these important things over the years, but I never bothered since for me, knowing them would not enable me to contribute. I work in the hardware industry of Silicon Valley, which is an overly-pleasant way to say I've signed a lot of restrictive Non-Disclosure and Non-Compete Agreements (NDA/NCA). Even if there was no violation of a NDA/NCA when contributing code, the cost of proving innocence is prohibitive, so the risks are not worth the rewards. In the lawsuit insane USA, the result could be bad for me personally, bad for the friends/companies I've worked for, bad for the project, and bad for anyone using the project code. Even if I had the required coding skill, my hands would be tied by the risks. If you are in a similar situation, the only good news is there is typically an expiry on NDA/NCA contracts, so eventually you'll get your freedom back even if there is no way to completely prevent frivolous lawsuits. Needless to say, since the project is code, it makes little sense to invite someone who cannot contribute code to a coding event like the OpenBSD hackathons.

Keeping with the idea of not dodging the difficult questions, my dad asked me a very pointed and provocative question when I told him about being invited to the hackathon. From the work he did before retirement, my dad knew of BSD UNIX from its early days at Berkley and other universities, so he understands it's quite an honor to be invited to go spend a week with the people continuing the tradition of BSD development. The tough question he asked was, "Do you think you deserve to go?"

bufq? bufq! Nope. Thankyou.
The reason why it is such a great (and loaded) question is anyone who answers "yes" probably doesn't deserve it, and would only cause more problems than they could ever solve. On the other hand, anyone who answers "no" probably doesn't have enough confidence to make significant contributions. Part of contributing is helping to get to the best answer, and getting to the best answer often involves being able to explain/debate the reasoning behind your opinion. Without confidence in your opinion, the best answer might not be reached. Also, you need the ability to accept when you're just plain wrong, be told in no uncertain terms how wrong you are, and still not take it personally.

The above was as close to an answer as I could muster. I simply didn't know if I deserved to go, but either way, I'd just do my best and be content with it.

Your idea of a fun vacation may be slacking in the sun on some exotic beach in an ugly Hawaiian shirt sipping a cold blue drink with a paper umbrella. Sure, that does sound like fun for most people, but for the OpenBSD developers, a fun vacation is traveling to meet up with the other developers and spending a week concentrating on making a project they care about even better. It's an entirely different world and only understood by those who truly enjoy and care about building the best operating system possible.

I tried to keep my expectations for my first hackathon within reason, but I still made plenty of mistakes. Since Theo knows my limitations regarding code, I was invited specifically to be a "test bunny" --the project always needs more people testing. My first thought was to drive a truck full of hardware up to the hackathon so I would be able to test anything and everything. Luckily, Theo said a truck full of gear would be unnecessary and also, he said the developers tend to prefer a quiet hack-room, so loud systems should be left elsewhere and controlled remotely.

The hack-room is a bit like being in a library but more friendly. It's mostly quiet with a few muffled discussions here and there at various tables throughout the room. On occasion, there's some loud joking around, announcements, or even big open debates. The debates are absolutely fascinating. People who know the very lowest levels of the code and most intricate details of hardware go through the merits and ramifications of potential ways to solve problems. Even when you do not understand all of the aspects of the topic at hand, if you quietly pay attention, you will still learn a lot from the exchange.

With my first mistaken expectation corrected, I immediately jumped to my next mistaken expectation, namely what kinds of quiet, portable systems I should bring for testing. Though I did not get this entirely wrong, my answers (detailed in Part 1 and Part 2) were almost equally excessive as the idea of driving a truck full of hardware to Canada. On the bright side, my misinformed expectations and less than stellar choices of test gear still worked out reasonably well, and as I had hoped, enabled us to find and fix some unknown or long standing bugs.

(click to see names)
I was under the false impression of needing to be prepared to test everything. I try to follow the source-changes@ and ports-changes@ mailing lists, so I had a rough idea of the kinds of things the various developers like hacking. I also asked a handful of the developers about the things they were planning on doing at the hackathon. Though I put a lot of effort into being ready for anything, the end result is I was overly-prepared and a lot of the stuff I brought was never used. None the less, if given the chance to do it again, and the choice between being under-prepared or over-prepared, I'd undoubtedly go for over-prepared. Let's just call it a known personality flaw I live with, and leave it at that.

Since I do research, analysis, automation professionally, I know a fair amount about meticulously building proper test environments. In my day job of working with hardware, companies are well financed so elaborate test equipment is available. On the other hand, in my own fun garage projects I just don't have the budget for fancy equipment, so I have to be clever enough to find other ways to get things done. At the hackathon, I was surrounded by very clever people who have spent many years learning the tricks and trade-offs of development and testing, both professionally and in their own fun projects like OpenBSD. It was extremely interesting and very educational to see how others go about getting things done. I learned a ton.

Having exaggerated expectations for myself was somewhat forgivable, but I know better than to have any expectations of the other developers. The developers spend their time hacking on stuff for fun and they really care about doing it right but placing expectations on them is both unrealistic and extremely unfair. Even though you may be frustrated by something not working as you wanted, it is really your responsibility to fix it. Expecting someone else to spend their free time fixing your problem is unrealistic and worse, very rude. Though many of the project developers are very quiet, some may try to help you find your solution, but it will most likely require you to put in some effort testing configurations or patches. The developers may ask you for something specific, and even if you don't understand why, do your best to give them the information they need, without wasting their time giving them stuff they don't need. It's a tough balancing act, but try your best. If you are polite, friendly and wise enough to refuse placing expectations on the developers, they will often respond kindly if they have the time. When you enjoy hacking on your own, try to help out with coding or testing, do your best to answer your own questions, and try to learn from your mistakes, then your efforts will be appreciated and you will be able to make real contributions to the project.

J.C. Roberts
"If you don't like the news, go out and make some of your own."
And of course, submit an article on it to undeadly!

(Comments are closed)

  1. By brynet (Brynet) on

    Mmmm, Tim Hortons coffee.

    1. By Anonymous Coward (anon) on

      > Mmmm, Tim Hortons coffee.

      "That's not coffee, it's a liquid doughnut".

      1. By brynet (Brynet) on

        > "That's not coffee, it's a liquid doughnut".

        I don't see the problem.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]