This was written in December, 1999
Lots of programmers want to get started on a free software project, but aren't quite sure how things work. This page is an informal collection of "unwritten rules and understandings" for people who'd like to volunteer. I learned some of this by making the mistakes, and I still flagrantly violate my own suggestions sometimes; these are only rough guidelines. :-) I'm sure other people would come up with a different set, too.
Don't start by launching your own project. Lots of people want to write free software, so the first thing they do is scribble some code, slap on the GPL, and release version 0.0.1 alpha. While fun and possibly educational, this is totally unproductive. Here's why:
Code, code, code. If you do start a project, the all-important thing is to write code. You have to code enough to make the app useful pretty much by yourself; this can be months or years of lonely work, unless some kind soul decides to help with your app instead of starting their own. :-) You have to release often, fix bugs quickly, and generally keep things exciting. When it comes down to it, writing a free application is a huge amount of work. If you're writing your own, schedule 10-20 hours per week, at least. Of course you can contribute to existing projects with less time than that. And schedule those 10-20 hours every week, for the forseeable future. If you can't commit this much time - don't even bother starting the project. If you can't write code, ditto.
Be a self-starter. Lots of people post their intention to write application X, or announce version 0.0.1 alpha, and then give up when they get no response. Face it; there won't be much response until you have users. And there won't be users until you write code. So you're going to be running on your own determination.
The same phenomenon plays out when asking for help. Ultimately, if a bug or misfeature or lack of documentation is in your way, you'll most likely have to get in there and fix it yourself. Hackers are fairly nice about helping newbies who don't know where to start, but sooner or later they expect you to be able to solve your own problems.
Use the mailing lists. If you have a question, ask on the list. It's sort of impolite to mail individual developers privately, unless you have reason to believe that they're the only person who can answer the question. If you mail the list, it lets developers share the task of answering questions. (If you use private mail, most likely you'll mail the wrong developer anyway, and end up not getting an answer because the person you mailed doesn't know.)
Mailing lists and documentation are set up by the developers to make supporting a large number of users feasible. Remember that everyone's a volunteer, and if you need it paid consulting is probably available.
No one is in charge. People often expect someone to be in charge of free software projects; or they expect to get an assignment, then have to complete it by a deadline. It just doesn't work that way. You can't control what other people work on, and no one's going to tell you what to work on, though there will probably be plenty of suggestions. You've got to dive in and make something happen.
Coordinate with others. If you spend 3 months writing some cool new feature, and then find out that the maintainer hates the idea and won't take the patch, or find out that your patch doesn't apply to the latest development version, or find out that someone else did the same work, you'll be unhappy. If you're planning to work on something, drop a short note to the maintainer so they know. Most maintainers will be skeptical - they get many such notes and then never see results! - but they will make a mental note and maybe give you some advice.
If you become heavily involved in a project, more fine-grained coordination is possible, usually using a combination of email, CVS, and IRC. CVS does a good job of merging changes when communication breaks down.
There is no answer to the question, "when will X be finished?" or "will feature X be implemented?" The answer to both questions is "when and if someone does the work." If the someone is you, then you know the answer. If the someone isn't you, then you'll just have to wait and see. :-) There's no manager and no one to make sure things happen.
Back-seat coders are bad. A back-seat coder seems to have an endless stream of brilliant ideas on the mailing lists, but either never codes or doesn't know how to code. If you don't know how to code, then you don't know how to design the software either. Period. You can only cause trouble.
There are lots of things non-coders can do though: bug reports, feature requests (as long as they aren't wildly speculative and totally unrelated to the existing codebase), write docs, help people with user questions and installation, user groups, web maintenance, server administration, making packages for OS distributions, etc. Hackers appreciate your interest in their work, and your assistance.
Lurking is good. The temptation to join a mailing list and start commenting on everything is strong. But don't become a back-seat coder. Post if you have relevant experiences, figure out how to reproduce the bug, have special expertise in the area, know the answer to the question. Otherwise don't. Also, it's always a good idea to lurk for a bit in a forum before you start posting, just to see what the culture is like.
Understand copyright, patents, licenses, trademarks, and so on. You have to be a bit of an armchair lawyer to get involved in free software. This means you have a responsibility to educate yourself. Traditionally, one way to learn is to watch the same tired flamewars go by week after week in the gnu.misc.discuss newsgroup. A faster way is to read the GNU website, in particular their analysis of terminology. Don't post on legal issues if you don't understand them. But you should understand them if you're going to be writing software and applying a license to it.
Respect the wishes of the package maintainer. It's always good to use the same licensing, coding style, etc. as the package you're submitting a patch for. If you're using CVS, don't commit to CVS without asking the package maintainer first.
Use the -u option to diff when submitting a patch. A minor point, but almost everyone prefers this patch format.
Remember that everyone's a volunteer. Treat them with the respect they deserve; they're only working because they enjoy it. It's quite lame to mistreat someone who's given you something for free.
Stay focused. Lots of us have trouble with this, but the more you can stick to a particular task and get it finished, the more useful stuff you'll achieve. I find that I have to pick small tasks to pull this off. Other people are better at the long-term projects. Organize your efforts to suit your personality. Try to finish projects, rather than starting 100 overambitious ones.
Learn about the community. It's a good idea to keep up with news sites, like LinuxToday, LWN or Slashdot and also sites related to the particular projects you're involved with. (The three I mentioned are just three that I happen to read.) A good book on the history of the community is called Hackers, written by Steven Levy. www.gnu.org has lots of info too, and lurking on mailing lists you'll learn a lot.
You will be flamed. As a rule of thumb, no matter what you do or say, someone is going to flame you. It's just the way of the Internet. Some people who haven't learned this lesson yet get upset and storm off as soon as it happens; don't do that. If you lurk on the mailing lists, you'll soon learn which people are likely to have valid points and which are just habitual flamers. (Not that the two are mutually exclusive; some of the most productive hackers are also huge flamers.) Develop thick skin, you're going to need it.
Have fun. Hacking is ultimately work; it's about sitting down by yourself and pounding out code or documentation. But there are lots of opportunities for socializing, at conferences, on IRC, via email. Writing the code is hopefully fun most of the time too. So, enjoy it. That's part of the point. Don't take this document, or any rules, too seriously.
Links: Eric Raymond's thoughts on this topic are here; his HOWTO describes how to join "hacker culture." The culture isn't really necessary to participate in free software projects though, IMO. As long as you follow the community way-of-working you don't have to get into the social aspects (unless you'd like to). Advogato (alter ego of Raph Levien) also has an essay, here. After reading all this advice, in the words of RMS, happy hacking!