In my previous post, I asked what it means to be a good maintainer on an open source project. I want to follow that up with a closer look at the interpersonal aspects of the job. These require skills that a conventional training in engineering is fairly unlikely to equip you with, so the whole area remains a challenge for many of us. This is why we sometimes end up working with people who make statements like, “don’t be offended, this isn’t about you,” when complaining about our contributions in ways that can’t help but make us take offense.
Of course, there are offensive people and those are best dealt with by other means. For those people who offend without intending to or even realizing that’s what they’ve done, I ask myself: Is there a way to lead this into more constructive collaboration?
I believe interactions between people are to, a large degree, things that we can learn to do better. As a maintainer and leader, this is an area in which I invest my time. I try to figure out how to meet individuals at the other end of the internet and bridge them to where I am, where the project is and where the community needs them to be.
To me, this is about acknowledging that, yes, actually this is about you. It’s also about me. So, why don’t we find a path forward together? This isn’t easy and it’s not always successful. But when I consider the people in my community out there writing, debugging and reviewing open source code, I feel an obligation to consider their needs at a human level and try to give them the leg up that they deserve.
The secret to avoiding interpersonal disaster as a maintainer is to remember that you are the defender of your project’s norms and culture. It’s your job to take the steps to ensure that your project has viability and sustainability in the face of challenges. For me, expressing this in the context of a challenge of some kind often diffuses a situation by demonstrating that I am pushing for quality software engineering on the project’s behalf, as opposed to feeding perhaps a stereotype of an arrogant, controlling egomaniac maintainer.
A key is that you can’t just do this passively. Advocacy and sponsorship are active things. You need to take deliberate steps to cultivate a positive social environment in which high-quality code can be created.
As a maintainer, you interact with people in a surprisingly wide variety of situations. These include:
- Code Reviews
- Delegating
- Status Checks / Project Management
- Meetings:
- Individual
- Team
- Architecture
- Implementation
- Marketing
- Building Your community
- Codes of conduct:
- Education
- Managing violations
- Security
- Incident response
- Responsible vulnerability disclosure
- Education
- Writing docs
- End user support
- Mentoring
- Growing reviewers / approvers
All of these are areas where a maintainer can set the right tone. For example, code review is rarely an up or down question. A good review is better thought of as a conversation with another human being. So, rather than starting out being nit-picky, it’s much better to look first for the positive and work from there.
I like Sage Sharp’s advice here. With code review you want to focus on three things in order:
- Is the idea behind the contribution sound?
- Is the contribution architected correctly?
- Is the contribution polished?
Code review embodies a general truth about open source: you reap what you sow. If you conduct your reviews with a positive and humane spirit, your code, as well as your community, are likely to be correspondingly attractive to potential collaborators and users.
Maintainers also work with people when delegating (in meetings and building community), and the code you collectively implement is shaped by the way those interactions are conducted. In addition, human interaction is central to functions like marketing and codes of conduct that don’t always get the attention they deserve. However, marketing is how you bring new people into a project and ensure its survival. Meanwhile, codes of conduct significantly strengthen a project’s culture, signaling your intention to be a place that’s free of destructive behaviors and where people can get their best engineering work done.
Equally foundational is the concept of non-discrimination, something that’s always been at the heart of the open source idea. From a business perspective, it means ensuring that others are able to build upon the code that you share. But it also includes non-discrimination at the human level. Anyone with a good idea should be able to express it in their project and have it lead to something else.
Few open source projects get everything right when it comes to maximizing the chances for positive one-on-one interactions. But to see a project that is doing a better job than most, take a look at Kubernetes. I’m personally involved with the Kubernetes Special Interest Group for Contributor Experience and have been thrilled at the efforts that the project is making to make Kubernetes a space that really welcomes and expects the best from all.
Finally: Don’t forget that you are human yourself!
Doing the hard work of creating a positive, humane project environment can be both time-consuming and emotionally draining. It’s no surprise that maintainers struggle with both time management and burnout.
As a maintainer, try to work on being able to:
- Manage your time efficiently
- Set boundaries with others
- Communicate with clarity and kindness
- Take breaks!
- Build in periods of relaxation to regain perspective
And lastly, think about succession planning. You don’t need to be a given project’s maintainer forever. Try to bring people up to follow in your footsteps so that you can hand the job off when you are ready. It sets up your successors for a new opportunity and frees you up to pursue your next big open source adventure.
