A community of communities: Empowering maintainers to grow communities around their code
TL;DR: In this talk from OSCON 2019, I walk through GitHub’s approach to empowering maintainers to grow a federation of semi-independent, safe, and welcoming open source communities that can scale along side the code.
Open source is about much more than publishing code. It’s about building communities around shared problems, communities no different than the offline communities we participate in each day. Yet, it can still be a challenge for maintainers of projects, both large and small, to grow safe and welcoming communities around their code.
GitHub’s Community and Safety team is like many other services’ Trust and Safety teams in that we are tasked with ensuring that users aren’t required to risk their privacy or personal safety to participate in the community on GitHub. Beyond discouraging disruptive behavior in the form of spam, abuse, or harassment, the Community and Safety team also goes beyond that and instead, actively seeks to encourage good online citizenship by both making it easier for users to contribute constructively and for maintainers to adopt community management best practices.
In this talk from O’Reilly’s 2019 Open Source Software Conference (OSCON), I walkthrough GitHub’s approach to empowering maintainers to grow a federation of semi-independent, safe, and welcoming open source communities that can scale along side the code, as well as what tools and resources are available today and in the future, looking at how various community management approaches encourage or discourage community growth and participation.
If you enjoyed this post, you might also enjoy:
- 10 lessons learned fostering a community of communities at GitHub
- Twelve tips for growing communities around your open source project
- Five best practices in open source: external engagement
- Why open source
- Resolutions for sustaining and growing open source communities
- Octoversary - eight years of optimizing for developer happiness
- Why you probably shouldn't add a CLA to your open source project
- Ten ways to make a product great
- Everything an open source maintainer might need to know about open source licensing
- 19 reasons why technologists don't want to work at your government agency
- User blocking vs. user muting
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 →