Everyone Contributes

TL;DR: 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.

2 minute read

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 lifecycle. 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 bugfixes 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.

Originally published August 11, 2013 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit