8

Dealing with Conflict

It’s natural to have conflict in open source projects, as a good project will bring together individuals from different backgrounds, cultures, and experiences. Those conflicts are quite often good, as they come from people expressing different opinions, approaches, and thoughts. Each person brings validity and merit to their area of focus.

That being said, coming together from different backgrounds, organizations, or locales can be challenging. I’ve similarly seen this with groups coming into a structure that is new to them, such as open source projects. The group might be used to how things work in their own companies but need help adjusting to a more open environment. Often, these changes are quite subtle, such as “We like using Box or Google Docs, not a wiki” or “We use WebEx or GoToMeeting, not Zoom, as this project does.” It might also be related to something such as decision-making, such as “I need to go and ask our company whether we can allow this code to be added.” These conflicts on tools and processes usually emanate from project participants who are new to a process and trying to understand how things work. However, there can still be underlying issues and frustrations that prevent people from coming out of their comfort zone. Addressing these issues at an early stage helps the issues not become larger concerns.

This chapter will dig into how to recognize when conflict can occur, how to best approach and manage it in a project, and how to remedy toxicity. The specific topics will include the following:

• Understanding people and their motivations
• Inclusive decision-making
• Remedying toxic behavior

When you see public conflict, such as explosive email discussion chains or people flaming each other in a chat channel, be aware that the antecedent for that conflict didn’t start then and has likely been brewing for quite some time. To gain this awareness, you need to understand people better. Let’s take a quick dive into that.

Understanding people and their motivations

In an interview, I was asked what the best and worst parts of open source are. In a somewhat knee-jerk and cheeky way, I responded, “The people.” My response was in no way meant to be derogatory but more of a reflection of the central role of people in the success and failure of open source projects.

To understand people, you have to understand how they think. Let’s take a quick dive into understanding the human brain.

The human brain

The human brain is a complex beast, controlling how we live, learn, react, and execute. What is most interesting is that different parts of the brain control different functionalities, as we can see in Figure 8.1:

Figure 8.1: A breakdown of regions of the human brain (https://commons.wikimedia.org/wiki/File:Cerebrum_lobes.svg)

Each section of the brain is connected to the other in many ways, and these connections are grown and weakened over time. Some of this is age-related, as children will not have all areas of the brain developed, while those later in life might have some degeneration that happens with age. Sometimes, people have brain injuries that damage sections of the brain, such as in a car accident. But these connections are mainly developed or impacted through life experiences.

There are two parts of the brain we will focus on in this chapter:

• Limbic system: This is responsible for impulses, reactions, and pure emotion and is often thought of as controlling the fight or flight response a person might have. I’ll refer to this as the lower brain in this chapter.
• Prefrontal lobe: This is responsible for executive functions such as decision-making, planning, and short-term memory. I’ll refer to this as the upper brain in this chapter.

As we go through this chapter, we will look at interactions and responses from the perspective of which part of the brain is responding. Generally, upper-brain responses will be more thoughtful, rational, and strategic, while lower-brain responses will be more reactionary, impulsive, and can be considered rude or inconsiderate.

The other aspect of looking at the human brain is understanding neurodiversity, namely the effects of different neurological disorders and conditions that impact reactions. The most well-known neurological condition is called Autism Spectrum Disorder (ASD), a wide range of conditions and symptoms that impact how we approach social interaction and behave in social situations. There is quite a bit of variability in this area, and I would encourage you to check out the US Centers of Disease Control’s (CDC’s) information on ASD (https://www.cdc.gov/ncbddd/autism/index.html).

With a better understanding of the human brain, let’s now look at the impact of culture and life experiences on how people act and respond.

Cultural and life experiences

Many life experiences are good. For example, getting a good grade in a class will build connections in the brain that good grades lead to positive outcomes. Winning a sports game builds the connection between hard work and the joy of winning. But some can be difficult. Being yelled at by a parent builds the connections between a behavior and a negative consequence. Losing money gambling can build a connection between taking chances and loss. All these experiences shape who we are, how we think about things, and how we react and absorb information.

With negative life experiences, the resulting impact on a person is called trauma. The trauma we often think of is related to serious threats to our physical safety, such as physical violence, loss of a parent during childhood, assault, or severe injury – you will see this called big-T trauma. But much more often, we see little-T trauma, which is negative things that happen in everyday life, such as losing an item, being treated poorly, or hearing disappointing news. Either way, these experiences will impact your response to situations and interactions with people.

Another element of life experiences is the culture we are in. This could be cultural as it relates to the region of the world or country we are from; for example, growing up in the United States is quite different than growing up in China, and someone living in France will have a different life experience than someone in Brazil. But it could also be living conditions; if you grow up in a lower-income household, you will certainly have different experiences, traumas, and life prospects than a higher-income household. Culture forms part of our identity, and understanding a person’s culture makes it easier to understand them.

Each of us has different life experiences, so those connections in our brains will be built separately. With different connections, this might lead to different outcomes when interactions happen. Let’s now look more at interactions within communities in this context.

Example interactions in an open source project

Let’s now look at a few sample interactions between project participants, thinking about what we learned in the previous section about the human brain. For each, we will both detail the interaction and then break it down to look at it from several different perspectives. Let’s look at the first from the perspective of a rude maintainer.

The rude maintainer

Let’s look at this interaction. For reference, Sally is a maintainer, while Bill is a new contributor:

Sally: I just saw your pull request; there are several issues.

Bill: OK, what are the problems?

Sally: Well, first, there is no documentation or tests. Did you read the CONTRIBUTING file?

Bill: Sorry, I didn’t.

Sally: Go back and read that first, and then send in a new pull request. I’m closing this one.

On the surface, you might look at Sally as a bit of a rude maintainer, whereas Bill is the victim of that attack. That is accurate; as we talked about in Chapter 6, Making Your Project Feel Welcoming, this sort of interaction isn’t a good way to make a contributor feel welcome.

But there is likely more to the story. After all, Sally likely didn’t wake up that morning and say, “I want to be a jerk to a new contributor today.” Consider the following:

• In some cultures, people are just naturally direct. Sally could be from such a culture, and her reaction is the norm.
• Sally might have ASD, and one thing we often see from those with such a diagnosis is a tendency to have a more “matter-of-fact” reaction and a high adherence to rules and policies.
• Sally could have been through the fiftieth pull request in a row with no documentation or tests and has become frustrated with contributors and chosen to air that frustration with Bill.
• Bill might not be that new a contributor, and he has made a bunch of pull requests over time and continuously doesn’t add documentation or tests, despite many times being asked to.

Note that Bill didn’t react much to Sally, which is a good upper-brain response. Bill might not even think of this interaction as rude or confrontational because of past traumas or from having similar direct feedback from previous managers, teachers, parents, and/or authoritative persons. This could also be because Bill is non-confrontational. Maybe Bill has seen a pattern of these reactions from Sally and/or other maintainers and has decided it’s not worth reacting to.

Let’s flip this around and look at the inverse example of a too-direct contributor.

The angry contributor

Consider the following interaction. Alice is the maintainer and Greg is the contributor:

Alice: Hi Greg, just reviewing your pull request and have a few questions.

Greg: OK, fine, what is it?

Alice: Yes, so I’m not sure whether you have looked through our CONTRIBUTING guide, but one important thing is adding tests and documentation...

Greg: Ugh, it’s too hard for me to write tests, and I don’t have the time to write the documentation.

Alice: Yes, but that is required.

Greg: Well, that sucks.

If you have experience in conflict resolution or management, you can see that Alice handled the situation quite well (and better than Sally did in the previous section). As we observed, Greg has a lower-brain response, while Alice kept her composure for the most part with an upper-brain response.

However, as we discussed in the previous interaction example, there is likely more to the story. Consider the following:

• Like Sally, Greg might have various cognitive conditions that impact interactions, resulting in him being more direct than socially appropriate
• Greg could have had several different projects or maintainers push back in the same way, which resulted in Greg showing his emotions and taking his frustrations from previous interactions out on Alice
• Greg might have been conditioned through past interactions to complain and push back on policies, and he has been successful in getting those policies ignored
• Sally might be a bit too much of a rule follower, and Greg’s contribution could be a few lines of code that another maintainer/project might see as not such a big deal

Sally, while responding well, could be perceived as being a bit “cold” toward Greg. This could be because she is anticipating Greg’s reaction, and/or she is a bit new to being a maintainer and is uncomfortable in these interactions. Sally could also be preemptively aware that Greg will likely have a lower-brain response and is intentionally responding with an upper-brain response to avoid negativity.

Observations from these examples

Both interactions focus on the same topic, but with different individuals interacting, we see vastly different conversations occurring. These interactions wouldn’t be ones considered to be entirely positive. They can either lead to further negative conflict (for example, Greg posting on Twitter on how frustrating it is to contribute to that project), the contribution never arriving as the contributor walks away, or possibly the contribution arriving. Still, that type of interaction is established as appropriate in the project. All three of these outcomes are only sometimes the best ones.

Here are a few other observations to consider:

• If this is the same project, having vastly different reactions from the two different maintainers gives mixed signals about the culture of the project. Is Sally the outlier, or is Alice? If it’s Alice, is she a dominant force in the project that everyone tolerates? If it’s Sally, is she new in the role, or is the project generally a bit uncomfortable for contributors?
• Various cultural, social, and cognitive conditions are at play in every interaction. Alice may be viewed by some as completely appropriate in her interaction, while others might look at Sally’s interaction as avoidant or disengaged. Be aware that each person looks at situations differently because of their background.
• With minimal context, it’s easier to say one person is right while the other is wrong. And as we looked at other possible dynamics at play, both persons could be right or wrong in how it was handled. Knowing the full story is key – but in the eyes of outside people, that story is not always evident.

A better understanding of people makes it much easier to navigate decision-making. Let’s build upon what we’ve discussed in this section as we examine how to achieve consensus inclusively in our next section.

Inclusive decision-making

A good open source project functions well by having the community largely aligned. I say largely because it’s nearly impossible to get everyone to agree on anything, both in life and in open source projects, but good projects have a degree of alignment in purpose and focus. Even minor disagreements create fractures and bring out many negative emotions when a project isn’t aligned. When the project is aligned, it has the resiliency to get past minor disagreements and drive forward.

You often hear a term in open source community management called “herding cats.” If you have a cat, you know that cats are often independent and difficult-to-control animals, and in the same way, trying to pull together large groups of people from different and diverse backgrounds can be equally challenging. So, how can we be successful at “herding cats”? Let’s consider some key things, starting with good communication.

Open communication and collaboration

In any group, big or small, communication is key. This is even more true with open source, as you have people from all over the world contributing predominately in an asynchronous way. Keeping communication open and inclusive is an intentional action. Best practices include the following:

• Have dedicated, open communication tools. Most open source projects will leverage an email mailing list, and email is a good lowest common denominator. It’s also great because it’s asynchronous, and mailing lists save archives, so you can easily track past conversations and discussions. I also see forum tools such as Discourse or chat clients such as Slack, Discord, or Matrix used.
• Also, be sure your collaboration tools are open as well. Most open source communities use their GitHub or GitLab organizations as a unified collaboration tool, but some also use wikis, which work well. Internal company collaboration tools such as Box or Google Drive tend to be poor choices, as collaboration is gated by default, and it’s challenging to get access or discover the collaboration without proper access.
• Some communities I’ve worked with have tried to drive decision-making over a chat client such as Slack, Discord, or Matrix. Because chat clients are synchronous, it’s not inclusive (not everyone can always be available simultaneously).
• With all that said, from time to time, you need to get people together to participate in a live conversation. If you need to do that, use meeting best practices such as providing a fair amount of notice (if it’s an online meeting, at least a week; for in-person, it should be several weeks), distributing the agenda well ahead of the meeting, and making sure any web conference tools used are accessible on several different platforms.

The key here is to ensure the project’s mediums for communication and collaboration are open and easy to access. Additionally, you want to ensure that communication and collaboration are fully driven using these platforms; if a project has too much conversation happening in closed channels, it creates unintentional divides.

Now that we have the right tools to communicate and collaborate, let’s see how to best make these decisions.

Methodology for making decisions

Transforming the herding cats into orderly, inclusive decision-making requires a good structure. This should be well defined in a project’s governance, as we discussed in Chapter 5, Governance and Hosting Models. Good decision-making has a few elements:

• Having a period for discussion and a period for voting: This keeps the focus separate and ensures alignment before going to a vote. It also helps solve the problem of someone in the middle of a vote throwing a wrinkle into a process (for example, someone saying, “Hey, we should chat about this aspect more” when you are partway through a vote).
• Give options for both a “for” vote and an “against” vote, as well as an “abstain” vote: Also known as “lazy consensus,” this provides space for someone who might have a conflict of interest to not submit a vote, or someone who doesn’t feel they have either the right context or a strong feeling either way to express their preference.
• Clear timelines to avoid a never-ending vote: Many projects I work on will keep a period for discussion open for a week, and then, if there aren’t major objections, the project will proceed with a vote that is open for a week. Depending upon your project size or the type of decision, you should consider adjusting this; the Community Specification process (https://github.com/CommunitySpecification) sets different thresholds of decision-making and the mechanisms for each.
• Who can vote/discuss, and how: This should also be outlined in the project’s governance, as we discussed in Chapter 5, Governance and Hosting Models. The key point is that voting and discussion on the issue being considered should be centralized so that all feedback can be gathered.

Important note

The Apache voting process (see https://www.apache.org/foundation/voting) is a commonly used approach that Apache Software Foundation-hosted projects and other projects adopt, as it’s well known and clear.

GitHub/GitLab-centric projects might choose to do this in the context of an issue or pull request, and both have nice features built in to require a certain amount of approvals before code can be merged in (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews and https://docs.gitlab.com/ee/user/project/merge_requests/approvals/).

Sometimes in projects, even with a clear methodology and tools for voting and discussing in place, votes need help to move forward. Let’s look at how you can unblock things.

Making decisions

Trivial decisions, such as merging simple pull requests, are usually easy to make, though they are not opinionated, as Parkinson’s law of triviality tells us (see https://en.wikipedia.org/wiki/Law_of_triviality). Opinionated decisions can be the most complex to get through, which can be opinionated based on personal preference (project logo designs are quite notorious for this) or more foundational (such as expanding a project’s scope or bringing in a major feature).

The tone of these discussions can lead to one of two possibilities having the effect of lots of conversation with little constructive outcomes, often referred to with the metaphor “signal-to-noise ratio,” alluding to a high level of noise or irrelevant or unproductive conversation relative to the “signal” of a topic or productive conversations. Typically, this indicates conflicts in the project, which can be good for getting a discussion happening, but it can also be off-putting for those who tend to avoid conflict or, as discussed later in this chapter, turn toxic. Here are a few strategies to consider:

• Monitor the conversation, look for possible actions and outcomes, and try to suggest them. Consider the following interaction between David and Amy on adding internationalization to a project, with David being one of the decision-makers and Amy trying to drive a vote:

David: I see a lot of projects just spin their wheels on internationalization, and it just doesn’t seem like something we should get into.

Amy: Thanks for the comment, David. Can you specifically outline why you believe they “spin their wheels”?

David: There are just too many languages to consider, not enough people to maintain all of them, and lots of tools out there, and it needs to be clarified which one to pick.

Amy: So it sounds like your concerns are related to (a) the scope of supported languages, (b) the ability to support internationalization for a given language, and (c) the tool to pick. Is that a fair summary?

David: Yes, I think that captures it.

Amy: Great! So I would suggest we augment the proposal to address these concerns, adding specific policies/plans for (a) determining which languages to support and what is required to support a language, and (b) a review of the tools and a decision on which ones to use. Would you agree with that, David?

David: I like that! Happy to help!

You can see here that Amy takes a broad comment, narrows it down to specific concerns, and outlines actions. Amy also does this collaboratively with David, validating his comment at each step in the process. David sees this willingness to work with him and offers to take part – exactly the outcome you want to see.

• Keep an eye out for people who can but aren’t voting, especially if they commonly do vote. It could be that the person is on vacation, or for some reason, they don’t have access to the accounts used before or are not getting the messages. I see a lot of situations where people get frustrated that a decision is made and they can’t offer their opinion or vote, and it all comes down to a communication gap for the aforementioned reasons. Taking that extra step of reaching out avoids this.
• For those people who aren’t voting, it could also be that they are uncomfortable raising their feedback with a group. Reach out and chat with them while trying to help them get that confidence; sometimes, they need to talk it out with someone. Alternatively, they might be concerned about negative or toxic feedback and need help navigating that. You want to be careful here not to take the full discussion offline and instead preferably help people to have the discussion openly.
• Know when to say when. This can be if a decision needs to be fully reconsidered, if there are a lot of problems with the decision to be made, or if there is a fair amount of misalignment. Stopping the voting process and going back to a design phase stops unproductive discussion. Consider this exchange with Bob, Sarah, and David, all involving pushback during a discussion after work was done on updating the proposal. Amy again came through to avoid an unproductive discussion:

David: I keep looking at this internationalization proposal, and I still don’t get why we should prioritize this.

Bob: I agree, there is a big backlog of performance bugs that I think are more important to our community.

Sarah: I understand your points, David and Bob, but we are making it really difficult for those in other regions to use our project.

Amy: This is a good conversation, and it sounds like there is a concern about prioritization and what is most important to our community right now. Would you all agree?

David: I think that sounds right.

Bob: Agreed.

Sarah: + 1.

Amy: Okay, let’s table this discussion and vote, and we can go back and look at doing a community poll to determine how to prioritize this versus other concerns.

David: I like it!

Bob: Sounds good! Happy to help!

Sarah: Me too!

• Similarly, if there is a fair amount of unproductive discussion blocking what appears to be a consensus vote, you need to curb that behavior as well. Let’s assume the issues on prioritization for internationalization have been solved, and now we have Aaron chiming in and taking the discussion off course among David, Bob, and Sarah. Amy notices this and successfully pulls the conversation back:

Aaron: I’ve read the proposal and it’s good, but it will be interesting to see what languages are supported.

Sarah: I agree. I wonder how many do we think there will be?

Bob: I could see three languages: French, German, and Japanese.

David: I’m not sure about Japanese; do we have a lot of Japanese users?

Aaron: That’s a good question. I’ve not seen many on the mailing list.

Sarah: Have we thought about Spanish as well?

David: That’s a good one too!

Amy: Hi, everyone! That’s a good conversation on languages likely to be supported. Do we need to align on this before moving forward with a vote, or can we figure this out afterward?

Aaron: Oh, sorry, no, I don’t see this as something blocking a vote.

Bob: Me neither.

David: + 1.

Sarah: Agreed.

Amy: Great! We will get the vote started at the end of the discussion period then, provided there are no further blocking issues.

As you can see, inclusive decision-making is a lot of work. But that work pays off in the end, as you avoid deeper conflicts by not only having decision-makers at the table early on but also seeing where conflicts start happening, and looking for constructive ways to bring them to resolution.

When not managed well, conflict can turn from constructive to toxic, which has a negative effect on your project. Let’s look more at how to remedy this.

Remedying toxic behavior

Toxic behavior can take several forms. It can be what is called flaming, which refers to individuals going back and forth attacking one another with those lower-brain responses we spoke about earlier in this chapter. It can also showcase itself with people disconnecting or becoming disengaged, or just people having short or trite responses in conversations. Both are highly disruptive, holding a community back and causing stress and friction.

Often, this comes down to communication issues, where there need to be collaborative and constructive conversations, like what Amy achieved in the examples previously in this chapter. Let’s look at another fictional example of such an exchange; here, we have Ray as the contributor and Sam as the maintainer:

Ray: I keep looking at this pull request to refactor some of the tests, and I’m not sure I understand it.

Sam: What’s not to understand? It’s simple tests.

Ray: Well, not all of us are as smart as Sam I guess.

Sam: At least I’m trying to make things better, unlike you.

Ray: YOU ARE CRAZY!

Sam: GET LOST, RAY!

I’ll stop the interaction here, as we all know where this is likely headed. But you can see that Sam is offended and comes back with a lower-brain response, and then Ray goes into his lower brain, and the conversation implodes. Not all of these interactions are direct like this; some take the form of being more passive-aggressive in tone, but the result is the same.

I had an experience like this in one project I worked on, where the maintainer coming in had a lot of frustration with the recommendations I was making and the support we were providing. This person viewed my interactions as being like a dictator. I viewed their comments as not having the intention of building an open community, so I was being a bit too rigid in my responses. We both had a bit of this cold war between us; we would interact on calls, but it always felt like we were trying to prove the other wrong in some way. It was certainly toxic.

One day, in our regular one-to-one call, I said the following to the maintainer:

Me: Hi! I think we are thrashing quite a bit, and I want to give you a chance to voice your concerns. To do that, I want to give you 10 minutes to share everything that is frustrating you. I’m going to put myself on mute so I can’t interrupt you but will take notes. How does that sound?

Maintainer: That would be great!

Note how I purposely used an upper-brain response as opposed to a lower-brain response. Certainly, I could have attacked him for the problems I saw in him, but if I did, I wouldn’t have given space for him to help me see the problems he saw in me. Going down the route of the upper-brain response gave us both space for a dialog to solve our differences, instead of creating more conflict.

The maintainer shared a number of concerns and, as it turned out, didn’t need the whole 10 minutes. I think it was therapeutic for both of us; that call and future calls discussed some of these concerns, but more importantly, it made us more conscious of how our actions and words were being perceived.

Looking at that experience and, to a degree, the fictional interaction below, here are some observations to consider:

• People want to be heard. When they aren’t, they will either retreat or flame back. Giving someone a chance to be heard validates them, even if their opinion isn’t one you agree with.
• Reviewing your own actions through the lenses of others helps you be more conscious of your actions. There’s a term called unconscious bias, which refers to bias we don’t see but is visible to others. This comes up largely in the context of creating inclusive communities where, because we come from different backgrounds, cultures, genders, races, or sexual orientations, we don’t see how the words and actions we use have an impact on those not like us.
• Remedying toxicity isn’t an overnight process, as there are feelings hurt on both sides that may take time to heal. In the example with the maintainer, it took several months for things to turn from toxic to positive; this doesn’t mean it became more toxic, but we both needed to go through interactions and see how we both could do better.
• It requires intentionality to resolve toxicity. I often wonder if I didn’t have that call with the maintainer how things would have turned out. Would the person have just left the project and things then improved? It’s unlikely, as the maintainer wasn’t the only person seeing that issue.

Toxicity is certainly something that can be avoided, both with good habits in communication, as we looked at earlier in this chapter, but also by recognizing when it happens and taking the time to resolve it. Additionally, projects should adopt a code of conduct to set the right expectations. Contributor Covenant (https://www.contributor-covenant.org/) is a popular one that is widely adopted.

Summary

This chapter scratched the surface of dealing with conflict, recognizing that it is good to have as long as it’s constructive. Projects I’ve worked on that had conflicts coming from vendors who were competitors tended to actually have a higher velocity of code and innovation than those that didn't. The same is true for projects with more diversity from different backgrounds, nationalities, races, genders, sexual orientations, and so on. That seems a bit counterintuitive at first, but if you think about it, having people in the room who all have the same experiences produces relatively predictable results. But when there are differences, we see a variety of perspectives and needs flourish, and that diversity brings new ideas and novel solutions. But when the conflict turns toxic, it becomes a distraction to a project and takes a lot of work and time to fix.

Handling conflict well is a centerpiece to being able to grow and scale as a project. Let’s look at the next chapter, where we will delve more into handling growth as a project.

Further reading

I encourage you to read more about diversity and trauma if you are interested in this topic, as there are professionals in this space that will help you be a more inclusive project. Here are a few:

• Karyn Purvis Institute of Child Development (https://child.tcu.edu/)
• Diversity, Equity, and Inclusion in Open Source report by LF Research (https://www.linuxfoundation.org/research/the-2021-linux-foundation-report-on-diversity-equity-and-inclusion-in-open-source?hsLang=en)
• CHAOSS Diversity, Equity, and Inclusion Working Group (https://github.com/chaoss/wg-dei)
• Software Developer Diversity and Inclusion initiative (https://sddiproject.org/)