Getting into NetBSD - How to Help

Jason R Fink <jrf@adresearch.com>

Abstract

This article discusses the different groups within the NetBSD Project and the variety of ways virtually any user can help the project.

Some of the material for this paper is taken from the NetBSD website. There is a list of reference URLs at the bottom of this page.

What Is A Developer/Hacker?

When most people who use the NetBSD (or any BSD) system think of a "hacker" or developer, the first thing that comes to mind are kernel developers. While kernel development is a very important part of the NetBSD system, the project as a whole relies on an infrastructure of groups to operate.

NetBSD Work Areas (or Groups/Teams)

There are many work areas within NetBSD. The following is a quick list of the ones that I know of:

• Accounts & Admin
• Announce
• Documentation (Not an Official Group)
• Kernel Programmers (Not an Official Group)
• Packages
• Release Engineering
• Security & The Security Officers
• System & Utilities Programmers (Not an Official Group)
• WWW & Mirrors

Thats a lot isn't it? Amazingly, some people even take on additional tasks of being in the NetBSD Core Group and/or a member of the NetBSD Foundation Board. The Core Group is an invite only group; their job is to help with the technical direction of the project while the Foundation manages the project as a whole. Now for a look at each "subgroup" and why they are important. Many readers may think, "well, I know the importance of each one" but in fact, one may not realize just how much work is involved in each group.

Accounts and Admin

This particular group of Developers is important because it is their job to make sure the project machines run and account issues are solved. One may think that with an Open Source project, this job would not be too hard. Guess again. This group gets subjected to CVS problems, server moves, solving network issues, and often works with the mirrors group to resolve mirroring issues. I am sure they do a lot more. Anyone who has been a System Administrator knows the difficulties of the job when they are paid for it - doing it voluntarily takes a tough cookie. It also requires experience. For example, even though I have been managing systems for over ten years, I would not qualify because of my lack of experience with administering NetBSD (only a few years now), and I am not as experienced with a lot of the software that project uses as the current admins are.

Announce

The public announce group has the tricky job of making public statements. I do not know how many people have done this for a project, but it is a lot harder than one would think. I have worked on public statement reviews and take my word for it, it is a pain. It is not just, say, writing a quick HOWTO where if you make a mistake - oh well, just fix it. In public statements you are saying "This is really really a big deal" and so the implication is "the wording and facts have to be perfect". This extra emphasis is true in any organization. Many companies make statements about products, how things are doing, and other news items off the cuff all of the time; however, when they make Public Announcements - well those are a completely different matter. Announcements also sometimes cross into the www group to be put up as news items, or sometimes the www group initiates Announcements.

Documentation (not officially listed)

The docs group works on system documentation (correcting man pages, on system documentation etc.) and many also work in the www group. There is also a "subgroup" that corrects comments in source code - these are mostly grammar errors and technical corrections as code is changed. The importance of this group is pretty obvious: the correctness and readability of manual pages is incredibly important to users. Proper grammar, especially in some of the very heavily commented code, can make the difference between understanding what is going on and being completely lost.

Kernel Programmers (not officially listed)

The kernel programmers have an important job, of course. They fix bugs, make improvements to, and enhance the NetBSD Kernel. Many kernel programmers, in fact, work in other groups. For example, if a kernel developer makes a change that affects a utility then they normally just go ahead and make the change to the utility as well. They often make first drafts of announcements concerning major changes and many help with documentation.

System & Utilities Programmers

This group works on everything outside of the Kernel. Again, many of the folks in this group work with the kernel, do documentation or work in some other group inside the project. This group has to face a lot of tough work since there are so many different parts of the NetBSD system to deal with. There is everything from handling bugs in /bin to mdoc issues. Actually, for novice programmers, this is a good area to get into by browsing the PR database. I guarantee that one will eventually find something to work on or at least test. This group also has to work hard around release time to make sure "all of the parts are in working order".

Packages

The third party package system is handled by a group of developers who import new packages, upgrade current ones, remove or mark broken packages, and constantly strive to make the pkgsrc system work better. While NetBSD alone can do a great deal of work, there is no doubt as to the importance of the pkgsrc system. Without the NetBSD package system, the work of adding third party applications would be quite difficult. The package team even goes as far as patching third party source (when it can) to make sure it runs correctly and is configured to run out of /usr/pkg. Not unlike Kernel and System programmers, the package team is always working, always handling problem reports, and always adding/removing packages.

Release Engineering

The release engineering (or releng) group is responsible for creating releases, managing release policy, and "pulling up" any changes into a release. Although I do not know much about this particular job, I have certainly heard it is tough. Not only does this group handle releases, they also teamed up with the Admin group to create build machines where periodic snapshots of -current can be found. Now, that has to be a tough job. Anyone who has tracked -current can just imagine how tough troubleshooting builds can be - all of the time! Part of the release engineering process many people never think about is getting volunteers to do builds and help shakeout problems before a release. Testing releases takes up a great deal of time and requires an immense amount of patience.

Security & Security Officers

The security group (in general) has to handle all security issues that arise on the NetBSD system. This means monitoring other general security lists, writing up Security Announcements, and testing/implementing security patches. The Security Announcements themselves are quite challenging to write. The announcement must be somewhat terse, completely technically correct, and provide adequate documentation on how to fix the issue. Almost every time an announcement comes out, typically, the administrator just rebuilds and reinstalls the affected software. The announcement is required to show these steps for each covered release plus -current.

WWW & Mirrors Group(s)

This group has the arduous task of maintaining the NetBSD.org website and keeping Mirror information up to date. The www group also has a lot of back-end programs in a few different languages that they use to make the site work. Last but not least, the htdocs system uses a make+perl system (to make list oriented pages) for most of the site. In a nutshell, the htdocs group has a lot of work on their hands. They also have a volunteer rotation who handles questions sent to NetBSD.org. Someone who joins the www group can quickly find themselves knee deep in work. When I joined I was (still am) part of www and the documentation groups. I was very surprised just how much my workload increased.

Translation Group

The translation group is sort of a subgroup of the www group. These stalwart folks translate the website and the NetBSD Guide into a variety of different languages. This helps the NetBSD system reach more and more users - literally - everyday.

Helping the Project

Now that all of the groups (both official and unofficial) have been discussed, it is time to look at how anyone can help. In a nutshell, there are actually groups one can make direct contributions to with diffs of source code or documentation. In addition to direct contributions, there are several other ways virtually anyone can help the project out, many of which do not require too much work.

Contributions to Specific Groups

Contributions to groups come in several forms:

• Code fixes in kernel and the system
• Documentation enhancements/corrections on the site and the system
• Adding new packages, reporting and fixing problems with currently supported packages

The one common thread here is to make sure you send the fix, enhancement or documentation to the correct group. The easiest way to make sure your contribution is correctly routed is to use the send-pr utility or the online send-pr form.

Other Contributions

Outside of sending code fixes, package work, and documentation fixes, there are a number of other ways anyone can help the NetBSD Project.

Money

Money always helps. Even the most insignificant amount may be enough for the project to purchase new test hardware, acquire documentation, or add new machines to the project.

Testing

Testing -current, kernels, and developer test patches can help out a lot. Just sending feedback that is nothing more than "it works great on my system" tells the developer that their code works. Tracking -current or just testing snapshots can go a long way in letting the project know where they stand with the system, especially close to release time.

Public Relations Help

One way anyone can help the project out that many people do not think about is Public Relations. Surprisingly, the Public Relations area has a wide array of things people can do to help the project get more attention. Following is just a quick list of ideas I tossed together, I am sure there are more:

• Spread the word by mouth (definitely the cheapest way)
• If you are good with art, make logos, posters, and other promotional art (and let the project know!)
• Offer to help at events at the booth and other logistical chores associated with events
• Write articles and papers that explain the usefulness of NetBSD at your site
• Write articles and papers about the system

Other Donations

When people ask for drivers, it is difficult to write them when the developers do not have the hardware readily available. If possible, consider sending hardware to the project to have a driver written for it.

Use the System

Last but not least, just using NetBSD helps out. In its own way it speaks for itself.

Summary

The NetBSD Project is organized into several very focused groups. Anyone can contribute to most of the groups directly and do a great deal more to help advance the project.

Reference URLs

The following is a list of URLs at the NetBSD website (http://www.netbsd.org/) that are related to sections of this document:

• The main page for making contributions to NetBSD:
  http://www.netbsd.org/contrib/
• The main page for NetBSD's Problem Reports database:
  http://www.netbsd.org/Misc/send-pr.html
• Groups within the NetBSD Project:
  http://www.netbsd.org/People/groups/