We often think of contributors as developers, but code is just one of the many ways to contribute to an open source project, and it’s important to provide avenues of participation for non-technical contributors as well.
Think through the spectrum of stakeholders that an open source project touches throughout its life cycle. On the one extreme, you may have a non-technical, non-user stakeholder, such as a boss, or the one paying the hosting bills, and at the other extreme, you’ve got a potential developer that hasn’t yet learned your project exists. I like to think that the list looks something like this:
- Non-technical, non-user stakeholders
- Potential users
- Veteran (or curious) users
- Subject matter experts (accessibility, content, i18n)
- Technical users
- Active developers
- Potential developers
Each of these potential contributors has a unique set of needs, but more importantly, has a unique ability to contribute in a way that others may not. What participation products are your project producing to satisfy a potential contributor’s itch at each point along that continuum? Does each have a clear path to contribute?
Think through their needs. A potential user, with a fresh set of eyes, is uniquely positioned to answer the question “does this thing do what it says it does?”, while a regular core contributor may be well suited to recruit other, not-yet-engaged developers. The possibilities are both endless and unique to your project, but to name a few:
- Kick the tires, does it work?
- Answer the question: “what features would you love to see?”
- Flesh out documentation, note where documentation is lacking
- Community evangelism, speak, teach, and spread your love for the project
- Submit new questions to the project’s Q&A forums, or take a stab at an answer
- Host a genius bar at the next local meetup
- Translate the project into a different language
- Give feedback on proposed bug fixes and features, propose new ones
- Recruit new developers
There’s a lot to be done, yet while most open source project’s READMEs outline technical requirements and how to submit a pull request, most are notably silent as to how non-technical stakeholders can begin to contribute, let alone provide sufficient encouragement to overcome the inherent scariness of trying something new. What if you could double the size of your open source project’s community over night?
Version your documentation along side your project’s source code, and encourage non-developer users to leverage tools like prose.io to submit improvements. Point non-coders to Issues, and get them involved discussing features early along the pipeline. Connect them with a local technology meetup, and let them teach others. Empower them to contribute any way they know how. Give them an out, and make the experience awesome.
Open source is described as community, but we have to realize it’s not simply a community of developers, nor should it necessarily be developer-centric. If you’re only explicitly providing avenues for contributions as code, sad to say, you’re ignoring half your community. Actively seek to minimize contributor friction, and strive to fulfill the implicit promise that if a community member has the contributor itch, not only can I quickly and easily find an existing opportunity to contribute, but that I’m encouraged to do so and have the tools that I need.
Ben Balter is a Senior Manager of Product Management at GitHub, the world’s largest software development network, where he oversees the platform’s Community and Safety efforts. Named one of the top 25 most influential people in government and technology, Fed50’s Disruptor of the Year, and winner of the Open Source People’s Choice Award, Ben previously served as GitHub’s Government Evangelist, leading the efforts to encourage government at all levels to adopt open source philosophies for code, data, and policy development. More about the author →