At the most recent US Open Source Summit, I offered some tips for people who are new to open source and worry about navigating the interpersonal politics that inevitably operate in open source communities – and I thought I’d share a few of them here.
An open source project at its core is a collection of people working on a shared idea, but they are typically attracted to that idea for a variety of reasons. There are the people who originate projects and feel ownership of them from the outset. Some of us work for companies that benefit directly from particular projects, and we’re being paid to help those efforts succeed. Finally, there are the people who are just passionate about a particular project and want to help grow it simply because they think it’s going to make a difference in the world.
The particular blend of personas that you find in any specific open source project will shape its culture and associated politics. And given the range of people that most projects attract, it’s no surprise that along with all the good stuff like working together to achieve more than anyone could on their own, these communities also have the potential for friction, misunderstandings, and leaving people feeling left out.
In my talk, I wanted to speak to the position that I think is the hardest to be in when it comes to navigating what you could call the politics of open source relationships: when you come to a project without the authority of being a founder or of working for a company that is paying you to support a project it wants to see thrive, but you are passionate about it and want to contribute and perhaps eventually help take ownership of it as a maintainer.
Someone like this is in a very different position from someone like me. They won’t have colleagues that they can call on to make connections and introductions. And they will be stretched for time because they aren’t getting directly or fully compensated for the work they are doing.
We shouldn’t underestimate how factors like these get in the way of feeling like you are part of a community – or of understanding how that community operates as a micro-culture, and thus knowing how to work successfully within it.
So what are some concrete steps that you could take to ease your way into a project and begin to have a positive impact? Here are six ideas, moving from the easiest to do to a few that are hard work but very much worth the effort.
- Get a profile picture. You can fix this in a minute, but it’s actually surprisingly important in the politics of open source. People who don’t have a profile picture of some sort on platforms like GitHub are often harder to recognize and remember by other members of a project. Yes, you might want to protect your privacy and not share an actual picture of your face, but it’s really worth creating something that is, in effect, a personal brand icon. Having an image associated with you makes you both more recognizable and more relatable, and that makes a big difference in the credibility you are afforded if you want to become more influential on a project.
- Pick your projects. The open source world is vast and you can’t work on every project within it. So don’t spread yourself too wide. If you’re interested in a very large project, like Kubernetes, pick one sub area to work in. But on a smaller project, you might just be joining a couple of others and get the chance to help maintain it very quickly. The most important thing is to pick something that you’re really passionate about and then try to find an area in that specific project that is lacking attention or needs some love.
- Give your maintainers a heads up. When you are new to a project and have an idea about how to resolve an issue or fix a problem that you’ve come across, your maintainer will be really happy if you check with them first before you issue a PR. Just reach out and ask if they think this is a good idea – via email, perhaps, or by opening a new GitHub issue with the description of what you want to add. Most open-source maintainers feel bad when people open PRs with huge changes that come out of the blue, or that turn out to conflict with other parts of the software that the PR writer might not be keeping an eye on, that they then have to close. And you the contributor – and anyone else who might have jumped in to address the PR – can do a whole ton of work before the close takes effect, resulting in contentious feelings all around. Better to check with your maintainers, ask them if this a good approach, and get their approval first. You’ll enjoy a more positive – and thus more productive – relationship with your maintainer and you’ll be making the best use of your limited time.
- Focus your pull requests. Sometimes I see people suggest that a good way to start out as a contributor is by making very small contributions. The idea is that small PRs are easier for maintainers to read and approve. But I think what’s actually key here is to keep your PRs focused. Have them do only one thing and make it very clear why you wanted to create this PR and what it does. That makes it easy for maintainers to a) understand what you are proposing, b) figure out the wider implications of implementing it, and then c) quickly accept it or explain why it’s not going to work.
- Be present consistently. We’re now moving towards things that take more time and effort but are still very much worth doing. You can have legitimate reasons for dipping into a project, making a couple of patches, and then leaving, never to be seen again. But that won’t help you gain the long term trust and respect of the project’s existing leadership. Instead, if you want to have influence and impact on a project, you need to be there consistently. So, work towards building a track record of fixing bugs, helping ensure that software is released in a timely manner and of taking ownership of any tasks that don’t yet have owners. Attend meetings when you can and generally show that you both care and can be relied upon to help. That builds your credibility and the trust that others in your community will be willing to place in you.
- The Golden Rule works in open source too! Finally – as I suggested, open source projects at their core are human communities, so it’s no surprise that they’re also exemplars of the Golden Rule: do as you would be done by. Being kind to others – i.e. not being a jerk – will take you a long way towards being accepted into almost any open source project and navigating its associated interpersonal politics. People are way more inclined to take you seriously and appreciate your work if they see that you’re doing it with the best of intentions and appropriate sensitivity to others in the community.
That last suggestion is perhaps the hardest to bring off, simply because being passionate about something can put you in a hurry to get things done. You certainly don’t want to lose that passion – but you’ll also have a lot more impact if you balance it with an awareness of community politics, as well as of the impression you are making and of the priorities and needs of others.
Of course, maintainers also have a role in helping their communities navigate the personal politics of any particular project. If you want to read more about that side of the equation and what maintainers can do to improve their community’s experience of working together, I recommend reading this two-part blog series on “How to be a Good Maintainer” by my VMware colleague and fellow Kubernetes contributor, Tim Pepper.
Stay tuned to the Open Source Blog for more on VMware’s contributions to open source and be sure to follow us (@vmwopensource) on Twitter for all the latest open source insights and updates.
