Tobias Schlitt posted an interesting list of rules on how to get started in an open source project. This got me immediately thinking about an interesting trend I've observed since I dipped my finger in the open source well. Often, helpful tips on what to do when joining a project are provided by experienced open source developers for the newbies, in the effort to make things easier for all.

However, even more important, in my view, is how an existing open source project reacts to an influx of new users. Do we chide them for lack of knowledge? Set up a mesh of obscure unspoken rules? How about yelling RTFM triumphantly? Marking a bug as bogus with a sarcastic joke? I am personally guilty of all of the above in my time.

What surprises me in retrospect is that I didn't really recognize the point where I crossed the line from simply contributing to an open source project to when I started running it. The fact is, when you don't have the karma (to borrow Toby's definition), nobody cares if you make a little joke here or there. Once you are a representative of a project, what you say and do matters, and things can get blown all out of proportion. So, here are a few rules for people "with the karma" that I've learned.

You might be thinking "I don't run an open source project" but in many cases, you become a representative (and therefore one of the people who run it) of the project the instant you achieve enough karma to commit code to CVS, so this post applies to just about all of us!

1. If you must criticize, criticize with a gentle and humble tone

I can't emphasize the importance of this rule too much. It takes courage to approach an open source project and to suggest that these people who have been around doing this for much longer should change something, especially since chances are the bug report/suggestion/whatever will sound stupid if the user is an outsider. In addition, users who are derided have been known to go to extraordinary lengths to "get back" at the project that shunned them, even if no shunning was intended. If you have to mark a bug as bogus, I've found it is not only nice but necessary to apologize for the inconvenience, and to provide a complete explanation. If you can't provide one, re-examine your assumptions: maybe there is some merit to the bogus report. In my experience, nobody complains if you bump a bug to a feature request and pop it to the next release cycle. If you have to say RTFM, don't. Just post a link to the manual page and a brief sentence describing the technical details of the solution the user needs to use, without implying anything about the user's intelligence, preferrably without any emotional content. You never know, this user may turn out to be your most valued developer a year or two down the line

2. Unless the evidence suggests otherwise, assume that users you don't know are not interested in committing to the project

The single most annoying thing, in my experience, is when a developer pops up out of nowhere and offers to help maintain a package, even emailing back and forth a few ideas, only to disappear when karma is granted. In my experience, developers look at open source a bit like relationships: easy dates don't always make the best spouses. The work it takes to get to know a project, to develop trust through the quality of code, to basically endure a trial by fire instills a well-deserved pride from the developers who survive it, and garners a longer term commitment. By all means, accept help from developers, but if a user isn't being persistent, reporting bugs, requesting new features - and providing patches - it means they would rather you fix the problems for them. Before I understood this basic truth of open source, I was very frustrated finding developers to help out. Now, new devs are popping up with a surprising regularity.

3. Despite the evidence, it's probably your fault

If more than one user asks the same question, even though the manual is there, and there is an FAQ entry, this doesn't necessarily mean that the users are all stupid. Most likely, if you browse to the project homepage, and there is no obvious way to search for answers, or the answer is buried 6 clicks deep and requires prior knowledge of manual structure to access, it's probably your fault. Use the innocent "dumb" questions of average users to gauge usability issues with the project. You might find that there is a simple restructuring that will eliminate the annoying questions and attract better developers in one wonderful patch set.

4. Follow the rules you apply to those with lower karma!

The temptation to abuse your power is great in all positions of power. Humans like to do things that others cannot do, even if it's simply because it is a pain to follow the rules. This, by the way, should tell you something about the rules (see rule 5). If you don't follow the rules you set for others, you are corrupt. It's unfortunate, but not complicated, and almost impossible to dig yourself out of. Corrupted people lose community standing and damage the essence of the project they are running, even if their intentions are generally good.

5. Don't apply new rules casually, and simplify if possible

Certainly, as an open source project grows, rules can be useful for creating structure, but often the rule would be unnecessary because the infrastructure (communication methods email/wiki/forum, bug tracker, manual) is responsible for the problem. For instance, there was a lot of griping on pear-dev about accepting/rejecting packages before Toby Schlitt coded the PEPr mechanism. Many political solutions can be fixed with a clever technical implementation. However, try not to "legislate" through your technical solutions. For instance, the PEAR installer enforces a number of PEAR-specific coding conventions in package.xml, and does so more in the latest 1.4.x/1.5.x installer. Although helpful for PEAR developers when releasing through pear.php.net, these technical solutions to a political problem are in fact now causing more trouble than they are worth for PEAR channels outside of PEAR.

6. Assume everything you ever say will become permanent and don't say things that will come back to haunt you

Not sure this needs elaboration. Let's just say stupid flame wars, personal attacks, cursing - these all fall under this rule's umbrella.

7. People like to improve their code, and like coding standards

Many blog posts I have read recently say they "hate" this or that aspect of some other project's coding standards. I used to get into the religious battle (for me it was the added bloat of spaces vs. tabs - until I got high speed internet), but the fact is coding standards make it more fun to code. People might complain about them, but it's a passing thing. Don't even insist on them, just calmly correct the mistakes and even the most fiery zealots will come around to reason. Suggestions to improve code are universally well-received if delivered with respect. Honest!

8. Assume there will be politics, and plan for them

As I said in a comment to David Coallier's blog post today, ideas are the currency of open source, and politics is the commerce. Without a free and comfortable exchange of ideas between very different view points, you don't have a healthy project. Most open source projects start out with a dedicated core of like-minded developers, and so it appears as if there are no political issues at all. The truth is that politics need to be factored into all planning. Design a clear and limited mission for the project, create a clear governance system with room for flexibility as the project expands, and for God's sake try to keep the administrative details out of the way of the coding!

9. You have two audiences: developers and users

There is an inherent conflict between the needs of developers, who wish primarily to code cool stuff, and users, who wish primarily to not have their crap blow up on the live site. Users usually get mad when you break compatibility, developers get mad when they have to keep it. Users get mad when there's no documentation, developers get mad when they have to write it. You get the picture. Seek strategies to bridge the gap between these two disparate audiences. The PHP project has a fantastic documentation project consisting primarily of people who do not actually develop the PHP source, and they co-exist quite peacefully and actively. Think along these lines, and jump at opportunities to help out users without alienating developers.

10. Dream big, baby. Plan for the future

People like to be involved with cool, life-changing things. Don't sell your project short, write great code, and solve intractable problems with beautifully simple, eloquent solutions, and do it all from the comfort of your living room. To put it another way, unless you are some kind of freak, you won't have the energy to sustain the initial push behind the project all by yourself for more than a few years. Make sure you're planning ahead for your inevitable retirement or at least scaling back involvement, and seek out proteges to take over the project. The more attractive the project is, the more likelihood you will find that magical dreamer who will carry the torch off into the open source sunset.