Resolutions for sustaining and growing open source communities
Perhaps one of the most memorable milestones in the scientific community this year was the release of the first image of a black hole. Like most technological advancements these days, this was made possible in no small part by open source software.
It took scientists years and a network of telescopes to process and produce the image of the supermassive black hole at the center of M87, a galaxy 54 million light-years away. Over 21,485 direct contributors worked on the software that made the image possible, but over 74,000 community contributors worked on the top 1,000 open source projects used in total.
As an open source contributor, an open source maintainer, and the product lead for GitHub’s Community and Safety team, I’m always thinking about ways to better support the open source community. With the new year upon us, I decided to write down my resolutions for how I can continue to be a better member of the community—and thought to share in case they help influence the broader community as well.
1. I won’t be a bus of one. I’ll make sure to pick up some supportive community members along the way
In software development, there’s the concept of the “bus factor” (or the “lottery factor” as I like to call it). How many developers need to win the lottery tomorrow (or tragically get hit by a bus) for the project to fail? If it’s just you, that number is one. As a project grows and matures, you want that number to be as high as possible.
Humans get sick or take vacations or get locked out of their account and a project shouldn’t grind to a halt as a result. It can be hard to know when a project goes from “my” project to a community project, but as early as practical, move the project to a dedicated organization and empower contributors you trust to take on additional responsibility.
Beyond better project longevity, most of GitHub’s community management tools are built with organization-owned repositories in mind, to encourage shared responsibility, so you’ll find more and more robust community management tools are suddenly available to your project.
2. I will be a gracious dinner party host to the open source community
Think of an open source project like the world’s most distributed dinner party. Just as you would at a dinner party, as the host, you want to welcome guests as they arrive, take their coat, offer them refreshments, and introduce them to other party goers to ensure they have a good time.
Open source is no different, except instead of taking coats or offering hour d’oeuvres, you’re offering documentation and your responsiveness. And just as a dinner party guest should take care to arrive on time or might consider bringing a small gift to thank the host, as open source guests, contributors should likewise be empathetic, supportive, and understanding of open source maintainers and what is often their volunteered time.
Being an open source maintainer is often closer to being a manager than it is to being an engineer. You often start a project to solve a specific technical problem, but as the community grows, to scale your own efforts and to have the biggest impact on your project, your role often shifts to solving the human and the workflow side of open source, rather than the technical.
Specifically, community management (moderation, delegation, and organization), marketing, recruitment and evangelism, automation and tooling, and providing “white glove” support to high-profile users. The more sophisticated the project, the less likely it is that maintainers’ primary contribution is in the form of code.
3. I will support maintainers in developing healthy, inclusive, and supportive communities
Think about an in-person community you’re part of. It could be the neighborhood or town you live in, the congregation at your place of worship, or your local bowling league. Communities are about groups of people coming together to solve a shared challenge (having a nice place to live, practicing one’s beliefs, or socializing).
Each community has its leaders (elected officials, clergy, team captains) and some form of codified ideals (legal code, religious teachings, league regulations). When you move that community online, the social norms that build a sense of comradeship also follow.
Open source communities are no different from those offline communities. Just as offline communities have a neighborhood watch alliance, online communities require community moderation tools to police their members’ behavior when it deviates from established norms.
As a member of the community, our role is to empower maintainers to grow healthy and welcoming communities around their open source projects. The goal isn’t just to prevent or reduce the visibility of disruptive behavior (blocking users or hiding content), but to actively encourage inclusive behaviors, even if they don’t have previous community management expertise.
4. I will recognize the differences between communities—and look to support their specific needs
Smaller, independent projects don’t necessarily need sophisticated workflows or community management practices at the onset, and often, that premature optimization can stifle community growth. I think of project growth through a “community maturity model.” Projects should often wait to establish formal or documented processes as they mature, and not before they need them.
If you’re prototyping a new library by yourself, you don’t need a code of conduct, mandatory forms for bug reports. If you get your first pull request, however, from an outside contributor, you may want to consider taking a critical look at your documentation, and if you’re fortunate enough to get additional contributors, beginning to formalize your contribution and review process.
That’s not necessarily true for organization-backed open source projects that can either anticipate the success of a project or have teams dedicated to establishing cross-project practices (an open source program office).
If you’re Facebook or Google and you’re starting an open source project, it may make sense to include a standardized code of conduct or contributing guidelines for all your projects on day one to start things off on the right foot and set yourself up for success as the project grows.
Whether it’s an image of a black hole or your favorite mobile app, software development is a team sport. When you import an open source library into your project, remember that you’re not just adding code. You are adding a team of developers to your project. As we head into the new year, I hope these resolutions will help us all continue to work on being better members of the community together.
This post originally published on Hackernoon.
If you enjoyed this post, you might also enjoy:
- Twelve tips for growing communities around your open source project
- Five best practices in open source: external engagement
- 10 lessons learned fostering a community of communities at GitHub
- Why open source
- 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
- How to make a product great
- 15 rules for communicating at GitHub
- Everything an open source maintainer might need to know about open source licensing
- Leaders show their work
- Five best practices in open source: internal collaboration
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