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.
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.
If you enjoyed this post, you might also enjoy:
- Five best practices in open source: external engagement
- Twelve tips for growing communities around your open source project
- Why open source
- 15 rules for communicating at GitHub
- 19 reasons why technologists don't want to work at your government agency
- Why you probably shouldn't add a CLA to your open source project
- Everything an open source maintainer might need to know about open source licensing
- Ten ways to make a product great
- Five best practices in open source: internal collaboration
- Eight things I wish I knew my first week at GitHub
Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, 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