OpenSource: Barriers to Collaboration and Health of a Community

Ultimately, the health of an open source project is measured by the production of useful code, and the broad adoption of that code. This is easy to spot in many examples, projects like the Linux Kernel, Apache Tomcat, Samba, GNU gcc, etc are so useful, and have become so broadly adopted that they are literally the milieu in which the modern world is embedded.

It’s easy to spot the successes. And it’s also easy to notice that there are thriving communities collaborating around such successes. It’s much more interesting to ask what contributes to successful open source communities.

I would maintain, that successful open source communities lower the barriers to useful participation. They lower the activation energy for innovative activity. Some of the ways they do this are rather obvious, and some are less so.

Technical Barriers to participation:

Is it easy to figure out where to get the source code?

Is the code easily understandable to someone likely to be capable of contributing?

Is it clear how to build the code?

Can someone qualified to contribute easily figure out how to usefully modify the code?

Is it clear and straightforward to contribute changes back upstream?

And are all of these true even if you aren’t already part of the ‘in crowd’ for the project?

Social Barriers to participation:

Is the community open to communication and participation from outsiders?

Is it clear and obvious how to become part of the conversation around the development of the software? Is it easy?

Can consumers get reasonable access to and attention from developers?

Legal Barriers to participation:

Are you using a standard license ((L)GPL, Apache, BSD, etc)?

Is your entire code base licensed under that license?

Is it clear to contributors what license they must contribute under?

Is it clear to consumers what license they are consuming under, and what they have to do to comply?

Evaluating Community Health:

The higher the barriers to collaboration a community raises, the harder it is for it to become successful. When starting an open source project, or evaluating whether to consume or contribute to one, it can be helpful to consider the barriers to participation, as early indicators of whether or not the project is likely to become or remain successful.

What other barriers to participation do you feel are important to be kept low for open source success?

Tim, a lot of the barriers to non-technical contributors often have to do with under appreciation of what they have to contribute. Testing matters rather a lot. Good documentation is very valuable (I even did a bit of that in addition to contributing code back in the day for Wireshark, when it was still called Ethereal). It helps a lot to have both an on ramp for such contributions and to value them.
They also serve, who do not write code.

Hi, Ed.
What do you think about barriers specific to nontechnical contributors?
For example, if someone lacks programming skill (as I do ;) but wants to give back to a project, what challenges might they face? I've seen a lot of people give back in the area of testing, documentation writing and translation, and these are often areas that could use a little more attention...
Is it as simple as posting a "help wanted" page with items workable by people with varying skills?

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.