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?
Not The User's Fault 
September 28, 2010 at 10:24 pm
[…] hard, test pilot | Leave a Comment In light of the idea that openness is hard work and that improving the discovery path for new contributors is a constant struggle, I’d like to do something to help make Test Pilot a little more […]
September 28, 2010 at 11:05 pm
I joined as an intern and I believe that the best way is to provide new contributors the same tools as I was provided as an intern. That is a mentor and a good starting task/bug. This should be someone who is familiar that the task, can provide more specific help and even filter through all the important documentation and pull out only the relevant bits for the task.
Contributors could visit a page listing available tasks with associated mentors and choose one that fits their interest and skills. Modules/projects could likewise list a mentor and tasks that is suitable for a new contributor.
Of course the downside is we risk spending resources mentoring contributors that will quickly “bounce-off”.
I also discussed with some of my classmates their opinions on contributing and found that the ones who were interested where afraid that their patch would be rejected.
September 29, 2010 at 4:26 am
I once had a little bug I wanted to fix in “Frogatto & Friends.” The project website directed me to the project IRC channel, where everyone was friendly and willing to help. I develop on a Mac, though, and the only person who had any idea how to make the program work on a Mac was away for the week. The friendly and helpful folks weren’t able to get the source compiling on my computer, so I bounced off.
Later on, somebody else fixed that bug, so that’s almost a happy ending.
September 29, 2010 at 10:43 am
This is especially intimidating for a casual contributor, who may have one bug they want to fix, without wanting to become a full-time community member. Their one patch may not mean much on it’s own, but there are likely to be thousands of others just like them, and that’s a lot of contributions to lose.
I had a patch for GNU wget that I submitted that took 2 years to get accepted. The project didn’t have a very active maintainer when I first submitted it, so it lingered until a new maintainer came onboard, got up to speed, and accepted it.
September 29, 2010 at 10:57 am
Maybe the barriers to entry are higher to occasional contributors. You have to learn all the new ways and specific rules of the project, in addition to the specific APIs and technical difficulties (IE. spaghetti code), all this just to solve one issue or two you may be interested in.
This “feels” not worth it, and asking someone in the project to explain seems like wasting her time as well (especially if you don’t plan to contribute often).
Now the better the code is kept (no spaghetti code, anyone can delve in “quite fast” and solve “their” issue by themselves without bothering a regular contributor too much) and the less technicalities there are to discourage people (coding style, compilation complexities or gotchas), the more occasional contributors will be likely to contribute (and come back).
Actually, the less doc you have to read before you can get to work, the better.
Now I don’t know how many “occasional contributors” there may be out there compared to the regular ones, and if it is really worth investing time to try and make it easier for them…
(About coding style, why not let people work on their patch as they like, then use an automatic tool to enforce a common project style when committing ? Maybe it wouldn’t be realistic ?)
September 29, 2010 at 11:15 am
Oops, Ted Mielczarek beat me on the “casual contributor” issue. 😉
BTW, the easier it is for occasional contributors to contribute, the easier the regular ones will probably find it as well.
But occasional contributors may not have the correct approach, or good enough knowledge, resulting in lowering the overall code quality over time… They will mostly do quick patches, but not the refactoring that is needed. This is a tough problem.
September 29, 2010 at 6:22 pm
for those wanting to add a feature (as opposed to fixing a bug) to a mozilla project (firefox), they should be redirected to building it as an extension (but we still need a good starting point for building addons)..
and i guess a mentor model might be great for people who are not students and/or don’t live in USA (who can’t be interns). if most mozilla contributors took an hour a week to mentor one contributor, even if only 90% of them bounced off after a month, it would still be a huge win!
September 29, 2010 at 7:02 pm
For designers it’s impossible to collaborate, it’s like no one needs us. Only developers who can close bugs have tasks to do, if you’re a designer you’ll never find something to do. Well, maybe documentation or wiki-something but nothing design-related. It’s frustrating.
September 29, 2010 at 8:09 pm
What worked for me getting involved with Mozilla as a contributor was doing it with a bunch of other students through Seneca’s course “Topics in Open Source”. Each of us had to select a student project (usually in the form of a bug) and then work on it in the form of dot releases out in the open. We blogged about what we were learning and working on and also developed relationships with core Mozilla developers who hung out in #seneca (on irc.mozilla.org) with us, often helping us debug the various problems we might run up against learning to hack on the mozilla code base.
I was lucky enough to work with Ted on the project I took on and he was exceptionally good at communicating and staying engaged with me while I worked on something that often seemed overwhelming and sometimes impossible for a newbie such as myself to accomplish.
I think the hardest thing for me as a new contributor was thinking that I had nothing to offer (at first) as a relative newbie to open source, and to programming in general. What I came away with though is that a lot of what works is not the raw programming talent but all of the ‘soft skills’ you bring with you – ability to communicate well in public settings (blogs, bug comments, irc), being patient but also persistent in requesting feedback on your progress, connecting with a mentor or two, consistent attendance in an IRC channel so you develop relationships with other developers on the project, and finally the confidence to take the bug and make it your problem to solve.
September 29, 2010 at 8:11 pm
I just want to add that the good humour, manners, and hard work that was so apparent in Mozilla’s core developers and then also in the larger community I later came to know better was very important to me as a new contributor. It was extremely comfortable and welcoming, and I suspect that being part of the Seneca class which had already gained a solid reputation helped with that where being a “stranger” off the streets might have been harder. A little hand-holding and intentional invitation to participate can go a long way.
October 4, 2010 at 12:12 pm
Hey! Cool to see you mentioning OpenHatch here.
The “bouncing off” problem is huge. Projects can do a lot to signal to new contributors that they’re welcome.
I wrote a little more about that here: http://blog.lydiapintscher.de/2010/10/03/designed-not-to-scale/
October 23, 2010 at 3:33 pm
Personally I find the OpenHatch approach a perfect idea. I didn’t had the time to go through the entire proccess, but find what you can do in a step by step way seems to be an awesome idea.
Video howtos
October 23, 2010 at 3:40 pm
Damn iPhone submited prematurelly.
Video howtos are very helpful, but they get outdated pretty soon. Take jetpack for example, the howto is great, but the state of the project is not clear anymore. Is jatpack already integrated in FF beta? Is there new instructions to build the extensions now?
I have a lot of trouble finding out how to contribute and where. I am not a native English speaker, so I prefer a step by step guide then the mentor idea. It gives me more time to break the language bareer and get to the code itself.