Open source has become the default for how the industry collaborates on code, but participating in open source isn’t just about pull requests and code reviews. In fact, in an interview with Chris Nauroth, a long-time Apache Software Foundation (ASF) member and committer to projects like Apache Hadoop, he suggested that sometimes the best contributions may not involve personally writing a single line of C#, and instead afford others the opportunity to write plenty.
What kinds of contributions, exactly?
Beyond code: Other ways to contribute to open source projects
The ASF has long offered positive guidance on how to participate in open source communities. And, as its website declares, “There is nothing at The Apache Software Foundation that says you must write code in order to be a committer.” Indeed, as Nauroth put it, at the ASF “we like to emphasize that there are many potential avenues for contributing to the community.” Of course, code is what most immediately associate with “contribution” in open source including small bug fix patches, new unit tests, enhancements to existing features, or new features.
But as important as code is, it takes more than code to power an open source project. Other forms of contribution that Nauroth highlighted are:
Great end-user documentation: “Many projects drive their documentation from some kind of markup language, such as Markdown, so in a certain sense, a documentation contribution becomes a form of code contribution, too.”
Testing and release verification: “A project’s release manager will prepare a release candidate and announce its availability via email distribution list. It’s then important to get as many members of the community performing their own independent testing of that release candidate and voting +1 or -1 on the release, depending on their test findings.”
Mailing list support: “Diagnosing issues for end users and replying with help is another important form of contribution.”
Design review feedback: “Major new features require an open design review, with community members debating pros and cons on mailing lists or JIRA issues. Providing your unique perspective in these design discussions is another form of contribution.”
Interestingly, according to Nauroth, “Community members that are invited to become committers and PMC [Project Management Committee] members typically have shown a history of participating in multiple types of contribution.” Not just code.
So where should someone begin their open source journey?
Make consistent, small efforts when contributing to open source projects
Madelyn Olson, a maintainer for the Redis database project, said that her role has tended to be as “ambassador,” someone who enables others to make larger code contributions: “Almost all of my contributions are minor. Normally I’m the one making small fixes all over the place.” Though Olson started small, eventually those consistent, small efforts resulted in her being asked to become a maintainer of the project, a signal honor.
So the first principle of open source contributions? “When I’m mentoring someone new to open source, the most important thing I want to impress upon them is that no contribution is too small,” said Nauroth. He went on:
At first, I felt very intimidated about sharing my work publicly for review by a strong technical community. I worried that if I didn’t present something groundbreaking, it would be seen as a waste of time. Instead, what I found is that open source projects are filled with thousands of rough edges: small bugs, erroneous documentation, insufficient test coverage, etc.
In other words, there’s always something to do, and consistency is the key. “Perhaps someone starts small,” he pointed out, and “gets excited to keep contributing over time, and then participation in the groundbreaking new feature comes later.” Or not. No contribution is too small, and many valuable contributions have nothing to do with writing code. Open source is all about community, and the best communities are filled with diverse people doing different things.