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.
Prior to GitHub, Ben was a member of the inaugural class of Presidential Innovation Fellows where he served as entrepreneur in residence reimagining the role of technology in brokering the relationship between citizens and government. Ben has also served as a Fellow in the Office of the US Chief Information Officer within the Executive Office of the President where he was instrumental in drafting the President’s Digital Strategy and Open Data Policy, on the SoftWare Automation and Technology (SWAT) Team, the White House’s first and only agile development team, and as a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director. His paper, Towards a More Agile Government was published in the Public Contract Law Journal, arguing that Federal IT Procurement should be more amenable to modern, agile development methods. More about the author →