OpenBSD Journal

FAQ: how to help for OpenBSD

Contributed by marco on from the dept.

Marc Espie wrote this very interesting FAQ on how to help out the OpenBSD developers.

I frequently get private emails of people telling me they want to help with OpenBSD, with nothing more attached...

So I figured it's time to explain how things work. Note that this is completely my point of view. I'll let other developers chime in, they may have some vastly differing opinions...

OpenBSD is completely a volunteer project, with very little management. Coming to us asking what you can help does not help us at all !

There are many things that need to be done.

At the same time, there is exactly zero thing that we can give you to do.

Various tasks require various levels of expertise, and specific knowledge in some areas. Until we know you, we don't have the faintest idea what we can ask you to do for OpenBSD.

Or we could give you some task, wait for you to complete it, and then check the result.

It doesn't help us at all!

- if we delegate something to you, then we have to wait for a random amount of time until we see some results;
- we will often have to invest large amounts of time in explaining what we want you to do;
- we will have to check the result VERY closely to make sure it is what we want.

All in all, it takes longer to perform this kind of delegation than it takes to do the work.

We don't have enough resources to invest the time into wannabe-developers, considering one out of 50 (with luck) will become an actual useful developer.

So, instead, you have to start working for yourself. Read documentation, look at mailing-lists. Fix known open issues. Port stuff that people want.

And don't get discouraged if we apparently ignore you. There are many pending submissions that we don't get the time to process (and sometimes, that we process much later). I don't know about my fellow developers, but I can no longer answer all the emails I got. Easy stuff gets done quickly. Stuff that is properly argumented gets done quickly... other stuff gets postponed, sometimes indefinitely.

For instance, ports that are already completely correct get committed quicker. Bug-reports which explain the problem correctly, come with a testcase, and a fix, and an accounting of all the checks that were done since then will get processed more quickly (for instance, if you fix a bug in the libc, it's better if you explain what the bug was, and that you actually did a successful make release with your bug-fix in place).

Do not start on big intrusive changes at first. OpenBSD is conservative. Big changes won't be accepted unless they go in the right direction, and it's pretty hard to figure out the right direction for yourself unless you ask.

OpenBSD is a maker's culture. Long discussions don't matter. Hard-proven code does...

Small things help: complete bug-reports are VERY useful, and we do read them.

There's a small test you can do: put yourself in the developer's shoes. How much time will it take to process your contribution ? if it's - well written; - to the point; - complete and easy to act on; - demonstrates that you understand what you're talking about;

(in short, if it saves us time vs. figuring out the problem by ourselves) then there's a much higher chance it will be used.

If we have to play ping-pong over 10 emails to get you to tell us what you're actually doing, then forget it. It's a lottery. You might get noticed eventually, but don't count on it...

(Comments are closed)

  1. By Rembrandt ( on

    Add it to the website... ;-)

  2. By Anonymous Coward ( on

    Hmm ... I think the sad truth is, that for most of use (like me!), it seems we can help most by contributing bits of money, and just leaving the developers alone to do their thing.

    1. By Marco Peereboom ( on

      You have no idea how true that is. I'd like to use this opportunity to remind everyone that OpenBSD relies on community donations and quite frankly those have been slow lately. Feel free to send heaps of cash to the OpenBSD project. It'll keep the servers running and the code humming.

      1. By Anonymous Coward ( on

        Yes. I had to do an MCS and work in programming before I was really able to appreciate just how big the knowledge gap (and let's be honest ... brainpower gap) happens to be =(

      2. By Anonymous Coward ( on

        I dp my best to buy releases, unfortunately my cash flow has been slow lately, making it hard for me to buy or donate stuff. I'll do my best to fork up the money for 3.8..

  3. By Janne Johansson ( on

    I must be cynical or something, but I read it as a FAQ on how NOT to bug
    developers with un-working stuff to keep from wasting their time. 8-/

    1. By Anonymous Coward ( on

      That is how I read it too, but not in a cynical way. If you are sophistocated enough that you are able to give the developers half-decent bug reports (as defined in the FAQ), then submit away! If you can only give a vague report, it probably isn't going to be possible for them to find and fix that problem (no matter how much they would like to be able to do so), and reading your bug report will probably just be another distraction. If you are like me, I usually only send in bug reports for bugs that I feel (largely a hunch based on experience) the developers will probably be able to reproduce very easily, and moderate my expectations (since I'm really not able to give a *good* bug report).

  4. By Anonymous Coward ( on

    Just a question: How much of the price of an OpenBSD release goes to OpenBSD? Producing CDs does cost money, I imagine. Just wondering which is more useful, financially: a donation, or a CD purchase?

    1. By Nate ( on

      Obviously, if you donate 40 dollars to the project they are going to get more money to use then if you spend 40 dollars on a CD.

    2. By Bryan Inderhees ( on

      Theo answered this in his Ask Slashdot article. Basic summary is that a little under half of CD money gets back to the project, T-Shirts net even less, and posters about break even (mostly because they also function as give-aways).

  5. By William ( on

    My impression about this article is that you are driving people away from getting involved. It may be true that, for the mean time, you may waste more time explaining things to sort of wannabe's instead of getting the job done. You get the job done then. How about this: Most of the materials are getting people started on hacking the Linux kernel. The Linux communities welcome people to join them. I still think that the you OpenBSD guys are really arrogant. You have got dead and still didn't learn the lesson. Why are you guys so reluctant to offer guidances and mentorings to the new comers? If popularity is a measure of the successfulness of an OS, then OpenBSD is definitely a loser - because you are pushing people away from your realm with your arrogances. We are not living all alone. We need to get along with different people. If they don't know OpenBSD, doesn't mean that they are dumb. They just need a chance to get started with. Among the *BSD variants, OpenBSD guys are the toughest to deal with. May be that's why OpenBSD chose a blowfish as its mascot.

    1. By Francis ( on

      I wouldn't call their responses arrogant. I think it is a case of frustration with too much to do and too little time and resources to do it. As they have mentioned before, users can help a lot by testing the new releases and reporting the bugs.

    2. By Anonymous Coward ( on

      > If popularity is a measure of the successfulness of an OS, then OpenBSD is definitely a loser - because you are pushing people away from your realm with your arrogances.

      If popularity is your measurement of successfulness, please use Windows. OpenBSD's success is its High Quality code and High Quality documentation, and it shows.

      This FAQ may seem arrogant, but would you rather have very limited resources building OpenBSD or wasted teaching every newbie wanting to join?

      Where do you draw the line for helping and wasting OpenBSD deverloper's time?

      This FAQ makes perfect sense without demeaning anyone.


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