Interview with Karl Fogel, subversion cat herder (get a login from bugmenot).
Random and inaccurate summary:
- Volunteers are in it for attention. Make sure to always comment on commits, even if you have only good things to say. (see also)
- Constant low hurdels are ok. Occasional high hurdles are bad. If just compiling the source code is a big hurdle, you won't get people involved, even if its easy from there on. For example, this is a problem with OpenOffice.
- Know your developers. Work out what they're getting out of helping the project, and what role they prefer to play. When you have a problem, maybe address a question on the mailing list to a specific person -- it'll really help keep them involved.
- Have a well designed website. Make sure everything developers will need (eg documentation) is available. Make sure they'll find it. Again, no high hurdles. One missing or buried key piece of information is far worse than the whole site being a little clunky.
- Be clear that it's a project in the commons, be clear about licensing, don't dither about being open.
- Have something people can download and start playing with right away. Even early in a big project.
The recurring point he makes is: no high hurdles. Lots of low hurdles aren't too bad. High hurdles are killers. Sums up the major problem with many open source projects. I guess it happens because once you've vaulted a hurdle, there's not motivation to fix it. Having someone who's role is explicitly to lower the hurdles is a really good idea.