Appendices  A: Getting OpenBSD  B: Helping OpenBSD  C: Contributing Here  D: Contributors  E: Suggested Reading  F: Graphics and Fun  G: Usage and Licence Index  Introduction  Using OpenBSD  The Desktop  Advanced Use  Networking  Administration  Appendices Complaints? complain > /dev/null		How to Help OpenBSD's Development  What is OpenBSD, really?  A Friendly Reminder  Potential Projects What is OpenBSD, really?   OpenBSD is a volunteer-based project, with Theo de Raadt as the only real management - keep this in mind when attempting to do something for OpenBSD, if Theo would not approve then OpenBSD will not either. OpenBSD is a dictatorship, where those who like the system work within it and those that do not are free to leave. If you don't love it, leave it. As Merle Haggard once said. A Friendly Reminder   Many of the jobs truly worth doing require advanced levels of expertise, and specific knowledge in some areas. Until developers know what it is that you can and cannot do, they cannot give you a job because what they may want done could be beyond what you are capablie of and that would waste both your time and the time of any developers involved; explaining things when they could just as easily be doing the work themselves. Thus delegation of jobs to random people asking for something to do may take more effort than it is worth.   What an interested potential developer should start with is work done on their own, reading documentation, looking at mailing-lists, trying to find fixes for known bugs, sending patches for those fixes in. Maintaining a port of a programme that people want is also very good for getting one's feet wet.   Don't be discouraged if at first glance it appears as though the developers have ignored your efforts. There are often pending submissions that noone has gotten a chance to look at, everyone has a life, even software developers, your submission may be sitting to the side until a particular person has the time to look at it. If this happens, don't just go e-mailing random developers, many get significant enough that they cannot read through all they get, just be patient, whatever is holding it up will be sorted out in good time.   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. Altering how the system works on a fundamental level will not go over well, 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 community of contribution. Talk is cheap, remember that maxim when trying to work inside or with the OpenBSD community, as great debates don't lead to anything, only code does. Thus to most developers only code really matters. That said, small things help, well flushed-out bug reports are extremely benificial, the developers do read them.   When making those well formed bug reports, put yourself in a developer's shoes. Be clear and concise with your submission, keep it to the point and avoid unrelated information, be sure also to convey that you understand what you're saying, if you're unsure what you're reporting, how can a developer be sure about it? If you include all the relevent data, how to reproduce the problem and a patch which corrects the issue, it's much more likely to be included than a report saying, "X.org crashes when I run xmms."   If a developer is going to have to play tag with you over a dozen e-mails just to understand what you're trying to tell them is happening, then you may as well skip making the bug report, it's as good as useless. You may have a developer see your poorly formed report and really want to scratch that itch, but that is like playing the lottery, you may get noticed, but you really shouldn't count on it. Potential Projects   The project always has many things that could be done to help, but there is no giant TODO just waiting for you to take a job and it would not be wise to go asking developers to get you a job that you can do, what you need to do is find a need and fill it.   However, things like improving man pages by submitting patches which contain additional details, such as HISTORY, AUTHORS, BUGS or clarification of already present information are always useful and generally accepted. Other tasks, such as merging redundant tools is of use to the project, as when wicontrol was merged into ifconfig, perhaps brconfig or lmccontrolcould be merged into the interface configurator as well. New drivers for presently unsupported hardware, such as bcw, performance improvements, and useful, liberally licensed tools, such as hoststated, are often accepted by developers and brought into CVS.
		This site and it's contents, however incomplete and poorly made, are copyright © 2005 - 2024 Nathan Montague and contributors. See the Appendix for details on licence and usage. This site is not affiliated with OpenBSD in any way, it is an unofficial reference which is available as an altruistic gesture. Server, bandwidth and assistance generously provided by Sirius Hosting.