Published on (
 See this if you're having trouble printing code examples

Big Scary Daemons

Contributing to BSD


"I'd like to help, but I can't code."

This lament has appeared repeatedly on the BSD mailing lists since I started reading them in 1996, and probably far earlier. The standard response is silence. After all, if you've decided you can't help, there's really nothing for anyone to say. What many people don't realize is that they can help, and in an important way -- BSD is not just a collection of computer code; it is both a community and a set of products.

No one's denying that the programmers are the spotlight heroes of BSD. Many of these guys have impressive skills, and most of us could never even dream of being the next Bruce Evans. Matt Dillon rightfully collected copious kudos for his stunning response to a bug report from Apple Computer. Each BSD team has its own tales of coding heroism. If you can't program your way out of a wet paper bag, however, you can still help. The basic question is, "what can you do?" Not "what does the project need," not "wouldn't it be cool if my favorite OS did such-and-such," but "what skills do you have right now?" Chances are, those skills can be valuable to any BSD Project, or to any other free-software project.

For example, I've worked for years in computer support. I also do an unhealthy amount of writing. Eventually, some publisher will realize what a masterpiece he's been blessed with in a submission, and my name will appear in the New York Times Review of Books as "the most screwed-up author of the year." Fame and fortune will be mine, to squander as I see fit, and I'll abandon the computing industry in favor of a life of indolence and dissipation. Until that day, however, I spend a decent portion of my time writing for FreeBSD. I just use a skill I already have, and enjoy using, to help the Project. I also use my computer support skills to answer email on the various lists. Both the articles and the support are important, at least to the people who receive them. Neither contributes to the collection of ones and zeroes that are sold as FreeBSD. Neither gets me that widely coveted email address. But any product is useless if you can't operate it. Plus, I don't want my favorite developer answering user questions; I want him writing code and fixing bugs!

If you truly have no useful skills, and you have no other ideas, just reread the documentation for your BSD, subscribe to the appropriate mailing list, and help other users. I started this way. If you elect to do this, I encourage you to politely guide people to existing information resources. When someone asks a question that is in the FAQ, give them a URL to the FAQ's main page. If the question has been asked before, suggest that they search the mailing list archives. If we can teach people to help themselves, we can reduce mailing list traffic. (As someone who's subscribed to thirteen different FreeBSD lists, I have to say that reducing mailing list traffic is good.) As the old saying goes, teach them to fish and we'll sell them fishhooks. After doing this for a while, you'll start to see things that the Project needs. One of those needs will match your skills.

When you see a problem that you think you can solve, stop for a moment and ponder it. If necessary, make a note of it and come back to it the next day. Is this really something you can do? It doesn't matter how dumb or small it is: can you actually sit down with your professional tools and do it?

Here's the big secret of getting things done in every BSD project. Everything that they contain is there because somebody saw a need that they could fill, and did something about it. NetBSD and FreeBSD started when a bunch of 386BSD patchkit users got sick of waiting for the next release. Mike Smith is hammering ACPI support into FreeBSD 5.0 because he thinks it's important. I didn't ask permission from the FreeBSD project before starting to write articles about it. You don't ask before answering mailing list messages.

As a long-time reader of FreeBSD mailing lists, I've seen many people with great ideas for programming projects. These ideas have been brought up on mailing lists and discussed at great length. Most of these projects die without a single piece of actual code. For example, many people have suggested porting IBM's JFS to FreeBSD. The general consensus is that this would be a good thing, and that the submitter should go right ahead. The discussion invariably tails off into implementation details. As of yet, no actual code has appeared. (There is a project up on Sourceforge, but at this moment there is no code on it.) As you might guess, this has generated a certain skepticism towards new projects among the people who actually write code. You need to remember this when making sweeping, all-inclusive suggestions.

Related Reading

The Cathedral and the BazaarThe Cathedral and the Bazaar
Eric S. Raymond
Table of Contents
Sample Chapter
Full Description
Read Online -- Safari

If your idea is large enough that you feel you'd like an outside opinion before starting work, use a mailing list. First, search the list archives for your topic. If you find a previous discussion of your idea, read it. You can assume that you would get a similar answer. At this time, everyone on the FreeBSD-hackers mailing list would probably keel over in shock if they received a post like "At such-and-such URL, you can find my initial patches for porting JFS to FreeBSD. I can mount a drive and create files, but upon creating a directory, weird things happen. This may destroy your data, fry your kernel, and upset your pets. I would appreciate any comments."

If nobody's previously beaten your idea into the ground, and you still want a second opinion, ask on a mailing list. If you really want their attention, you need to be very brief and to-the-point. Most truly useful ideas can be summarized in a single sentence, or two at the most; anything after that is implementation details. Remember, some people get over two thousand pieces of email a day. A simple post saying "Hey, would people find this useful?" is a great way to tell the difference between a boneheaded waste of time and a serious need.

Avoid ideas that boil down to "Why doesn't someone else do the work for this?" Most of these suggestions fall into three categories: obvious ("Hey, wouldn't it be cool if we supported the CPU in my automobile?"), foolish ("Why don't we have a kernel option READMYMINDANDDOWHATIWANT?"), or both ("Why not support my Sinclair ZX80?"). In all of these cases, the person asking is almost always completely unqualified to actually do anything about the matter, and doesn't even offer to buy a drink for those who can. You can generally rest assured that the people who are qualified to do the work have considered these ideas and are either doing something about it or are working on more important tasks.

You can't expect a thousand people to respond with "It's a great idea." The mailing lists are public discussion boards. If everyone agrees with a message, they won't all post "me too!" But if you get a few people agreeing with you, and nobody says, "Your concept is so awful that it simultaneously sucks and blows," you can generally assume that it's a decent idea. This is the closest thing FreeBSD has to "management buy-in." You can consider this full-blown approval.

Occasionally, someone might write you back saying "I think Fred's working on that, why don't you drop him a line?" You might find that you can join an existing effort. Other people will want to discuss the implementation with you. You can take this as approval; they wouldn't bother discussing the fine details if they didn't like the idea.

The same sort of thing applies to every portion of every BSD. Can you translate the OpenBSD documentation into Urdu? Yep. Can you start a NetBSD users' group in Topeka? Absolutely. Check to see if anyone's already working on it, and go do it.

This is perhaps the most vital part. Once you have buy-in, go do it. Shut up and start working. Most of the ideas I've seen on the FreeBSD lists die on the vine. There is a huge amount of basic grunt work that can be done. Nobody bothers to do it, so it doesn't happen. All of the BSDs -- indeed, all open source projects -- suffer from this to some extent. Non-programmers can ease a vital gap by simply picking some little hole and doing the work to fill it. Some people set up independent Web sites, such as Dan Langille's excellent FreeBSD Diary. The committers and contributors directly enhance the bits that the Project produces. Others are just known as "that dude who hangs out the mailing list and helps people with PPP." All are absolutely vital.

For example, Dave Hawkey wrote the FreeBSD-hackers with an old idea. You don't recognize the name? I'm not surprised. You won't find his name on a commit bit, or the PR database. He's just a guy who wanted to provide small patches for older versions of FreeBSD, so that users with a particular problem could have a bugfix or improvement without having to upgrade their whole system. It's a great idea. It can be expressed in a single sentence. People would enjoy having it, and would actually use it. It's been brought up before, many times. If you check the mailing list archives, you'll see that this it's been discussed to death. This particular dead horse has been beaten beyond recognition, sold for glue, distributed across the country, and eaten by several thousand kindergarteners. Nobody has ever actually done anything about it.

This started the usual process that occurs when ideas are suggested. People generally agreed that it would be nice. Nobody said that it was a bad idea. People made suggestions about how it could be improved.

Unlike everyone else who has made the suggestion before, Dave actually created a site where people could download actual tested patches to actual source code. There isn't much there at the moment, but as time goes on, it'll build up. People will submit their own patches. Eventually, I expect it to be a well-known resource for people who cannot easily upgrade their systems. These users will be happier for knowing about it. When he quits one day, hopefully far in the future, there will hopefully be enough there that some other person will grab the existing patches and build upon them.

The important thing is, Hawkey isn't a FreeBSD community name. He's not even "the guy who hangs out on the mailing lists answering questions about file permissions." He's just this guy. He wanted patches, and nobody had them. Instead of going away unhappy, he shut up, produced them, and put them out for the world to use. If even half of the people who suggested ideas did as much, BSD would have taken over the world already.

The upshot of all this is: do something. You have skills; if you truly want to help BSD, you can. If what you want is to become a godlike kernel programmer, you can do that too; it will just take a few years. Or, as a well-known philosopher said, "Do, or not do. There is no try." Next time, we'll look at what can happen when you do a job too well.

Michael W. Lucas

Read more Big Scary Daemons columns.

Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.