Open source contributions go far beyond code

If someone says “open source” to you today, you will probably fill in the rest of the phrase with “...software.” Someone like me, who works for Red Hat, is bound to do this too, if only out of habit. 

Since the term “open source” was first coined in 1998, software was indeed the only noun being described by this adjectival phrase for a long time—at least in the public domain. In the hallways of intelligence services around the world, “open source intelligence” was gaining traction around the close of the 20th Century. As the new century began, people started to take note of how code was being shared and began to apply the ideals of sharing and collaboration to other things.

Expansion of open source

Gradually, the ideas of open source hardware, open source medicine, open source education, and a host of other shared creation models were being introduced to the world. The idea of many collaborating on a creation in ways that would surpass the work of one or the collaboration of a few was too appealing not to take root in other creative endeavors.

As prolific as these other expressions of open source are, open source software still gets a lot of the attention. We can easily admit to having a bias on this point. But it’s important to recognize this bias within the technology sector, because it affects how people perceive open source communities. 

More than one way to do it

Here is the problem: someone builds a community around open source software creation, and the automatic assumption by many is the only way to contribute to that community is via code contribution. In other words, open source projects are a developers-only club.

This is  a misperception my colleagues and I are very quick to correct.

There is no denying that developers are a key part of any open source software project, but they are certainly not the only key part. In any given open source project, there is a variety of other content beyond the code that needs to be created to make the project successful. 

Roles in open source projects

The most obvious is a project’s “front door”: the project website. If you review all that entails creating a site, there are quite a few roles that people can assist with:

• Designer

• Web developer

• Content creator

• System administrator

• Content manager

It is possible that just one or two people can fulfill those responsibilities, and they could also be developers within the project, too. But the idea here is that they don’t have to be. Projects have lots of room for non-developers to participate.

Red Hat’s Open Source Program Office firmly believes that open source projects have communities that are composed of two sets of members: consumers and contributors. 

Contributors are those who work to advance a project—mostly through creation, but not always even that. A community member who successfully settles a dispute on a mailing list isn’t creating anything tangible, but their presence and skills are benefiting the community and the project. 

Contributing beyond code

The source in open source projects is not always code. It’s documentation, web content, and  social media. It’s systems administration, content management, and quality assurance. The source is any aspect of an open source project, and because the source can be nearly anything, any contributor interested in being part of a community should be able to find the source with which they can work.

As community leaders and architects, the key is to examine your community and determine how tasks and responsibilities can be delegated out to more than just developers, and be more inclusive with the project’s processes. Establish who are the best fits to help build and maintain these different aspects of the community. Build process-oriented and culture-oriented paths to guide these new contributors into your project. You should soon find that the diversity of insights and creativity alone will bring a richer community experience to your open source project.