One of the reasons that Openness is a lot of work is because you need to create a path for new contributors to A. discover your project and B. figure out how to make their first contribution.
It’s not easy to get this path right! I myself have “bounced off” of several open-source projects, so I know what it’s like. Potential contributors come in eager to contribute something to the project, but they get confused about how to proceed, or they’re met with a total lack of enthusiasm, or they have their contribution rejected due to technicalities like not following correct coding style. (I know that coders have strong feelings about whether to put spaces inside of parenthesis or not, but is it really more important to enforce this than to gain contributors?) Anyway, they get discouraged, lose their motivation, and “bounce”. Even when people are willing to contribute for free, their time is still valuable to them, and if they don’t feel a sense of progress soon, they’ll invest their time elsewhere.
I recently gave a recruiting talk at a university, and met a bunch of students who were eager to contribute to Mozilla. They asked me how to get started, and I realized that I don’t have a good answer. If someone wants to contribute to Test Pilot (yes, please!) do I start by directing them to the Google discussion group? The #labs IRC channel (which is dead most of the day)? Do I point them to the open Bugzilla tickets? Or do I ask them to read several pages of Wiki documentation (some of which is may be out-of-date) just to get up to speed, before doing anything else?
If you want to get involved in Test Pilot, the openness is there and the information is there; but the information is spread out across a world of different websites, mailing lists, and other services, and it’s all rather overwhelming. Where does a prospective volunteer get started? This is not a problem unique to Test Pilot, of course; all of Mozilla struggles with it to some extent.
I’d like to hilight a couple of links that show promising approaches to removing obstacles from the discovery path.
First is the work Richard Milewski, a community member (and frequent Design Lunch participant) who pointed out to me how hard it was for someone outside the Mozilla organization to make sense of the raging river of information we output and figure out what was important. Rather than just complaining, though, he went ahead and did something about it – he built a website called Mozilla Express to aggregate in one place all the information sources he was interested in.
The second is OpenHatch.org, which aims to be a one-stop portal where you can find open-source projects that need help, find something that needs doing, and find out exactly how to do it.
I’d be interested to hear from you about your experiences on either side of the discovery path – if you’re in a project, what have you tried to do to make it easier for newbies to get started? If you’ve been that newbie trying to join a project, what was your experience like and what made you stick with it or give up?