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