For a community founded on peace, love, and free-flowing code, the open source community can be a difficult crowd to crack. As new academic research details, newbie developers often struggle to find acceptance in established open source communities for a wide variety of reasons.
As much as we may want to think of open source communities as welcoming meritocracies, the reality is much more nuanced. For those thinking of contributing to an open source project, here are the top obstacles.
Not surprisingly, developers can be a prickly lot. Even when they're not, it's hard to break into an established community where everyone knows each other or, to the outsider, appears to.
Yes, code is supposed to be the only hard currency in open source, but as one developer told researcher Nicholas Ducheneaut, "What the newcomer has to learn is how to participate and how to build an identity that will help get his ideas accepted and integrated."
This can be hard for developers new to a project, because "many would-be devs are intimidated by the perception of an existing 'in-crowd' dev group, even though it may not really be true," ActiveState vice president Bernard Golden told me. Developer Tony Li echoes this, suggesting, "There is often a intimidation factor when thinking about submitting code to the maintainers (even though it is not on purpose)."
Then there's the timeliness and quality of the response to new developers' questions. As research Vandana Singh finds, "almost all non-returning newcomers can be attributed to not receiving a response or receiving a condescending response." It only takes one flaming message from Linus Torvalds, for example, to keep many from coming back.
Here's one example:
It would take a very brave C++ developer to withstand Torvalds' volley and keep contributing. Yet some do.
That said, it's not surprising existing members don't want to spend a lot of time coaching newbies. As one HackerNews commenter states:
[S]mall projects get lots of, well, basically useless people who need tons of handholding to get anything accomplished. I see the upside for them, but I don't see the upside for me: If I were to help them out, I'd spend my limited available time on handholding people who apparently managed to get [Masters] degrees in [Computer Science] without being able to code instead of doing what I enjoy. So I ignore them....
We're always open to helpful people, but I have a depth 1 decision tree for ignoring the idiots: If you can't successfully read and follow the instructions in
make, you're worthless and I kill your email.
It's harsh, but understandable.
Still, it's a delicate balancing act. Developers who stick with a project tend to be mentored into the project. The more new developers interact in positive ways with a project's central developers, the better their odds of sticking with that project and contributing in significant ways.
Knowing what to write
While personal interactions make a huge difference in welcoming in new members of an open source community, none of it matters if the developer can't quickly find something useful to do with her time.
Getting to this point is partly a matter of documentation, as Cloudera community lead Justin Kestelyn highlights, because documentation can serve to illustrate not only what needs doing, but also how to effectively contribute to a particular project. Unfortunately, outdated documentation is often left sitting around, which can confuse developers and waste cycles as they write code that has already been done.
Documentation becomes even more important for monolithic projects like OpenOffice. The best open source projects are highly modular in nature, making it easy to pick off discrete functionality to contribute. Monolithic code requires far too much expertise for newbies, so it tends to attract only those paid by their employers to slog through the code and associated documentation.
Of course, project members can help ease newbies into the code by pointing to areas in need of contribution. But this rarely happens.
As Georg Von Krogh, Sebastian Spaeth, and Karim Lakhani note in their 2003 paper "Community, Joining, and Specialization in Open Source Software Innovation: A Case Study," the good news is that "in 56.7 percent of the cases, members of the community encouraged the new participants to find some part of the software architecture to work on that would match with their specialized knowledge."
The bad news? "In only 16.7 percent of the cases, new participants were both encouraged to join and given specific technical tasks to work on."
In other words, sometimes we're welcoming. Sometimes we're specific about what to do. But rarely are we both. That's a problem for new developers.
An open open source community
Which brings us back to where we started: It turns out that there's no easy way for newbies to find their way into an open source project except by 1) writing great code, and 2) being resolute in the face of existing developers either criticizing them or ignoring them.
Open source communities, in other words, are like any other communities. Some are more welcoming than others, and some are more worthwhile than others. But all require effort on both the parts of the community and those seeking admission.
This story, "How to crack an open source community" was originally published by InfoWorld.