Contributing to BSD01/17/2002
"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 @FreeBSD.org 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.
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.
Pages: 1, 2