Teaching open source communities about conflict resolution

At OSCON in Portland this year, Donna Benjamin and Gina Likins are combining forces to talk about a topic that is sometimes easily dismissed: conflict resolution. Given the growing need to address conflict in technology, and that even popular projects like the Linux Kernel adopting codes of conduct, it’s no surprise that conferences feature talks on human interaction.

In this interview, Donna and Gina answer hard questions on what conflict resolution looks like in the open source community, how to engage with the engineering community on the topic, and how to encourage communities to focus on respect and compassion as a basis for resolution.

Gina and Donna, you willl both be talking about conflict resolution—a topic near and dear to my heart. What sparked your interest in the topic?

Gina Likins (GL): I have always been passionate about ways that we can make online communities better, and in the past my focus has been more in the area of defining potentially harmful behaviours (hopefully in a humorous way so that people can see them). Interestingly, though, I am rather conflict avoidant, so it's been wonderful working with Donna, who has shown me the benefit of viewing conflict as a rich source of potential ideas and energy when handled well.

Donna Benjamin (DB): A couple of years ago, Dries Buytaert, the founder of Drupal, asked me to join the community working group. It was part of a push to bring more formal and structured governance to what had become a very large and successful open source community. The Drupal community had some "unfinished business," so to speak, which was to put in place a conflict resolution policy and process. That work led me to explore the nature of conflict itself.

With Donna in Australia and Gina in the United States, how did the two of you meet and agree to collaborate on your talk for OSCON?

GL: Donna, whose presentation had already been accepted for OSCON, saw the ApacheCon 2015 talk I gave and reached out to me via Twitter. After the initial schedule wrangling, we "simul-worked" (I’m going to pretend that I didn’t just make that word up) on a Google Doc, while having a Hangout and discussing our ideas. Thankfully, technology has gotten to the point now where this sort of cross-global collaboration is really easy. The hardest thing about it was eating dinner early enough that I'd be ready for an 8 p.m. call!

DB: Ha! So, Gina and I haven’t yet "met" in the real world. I'm really looking forward to doing that, and putting the finishing touches on our presentation in-person. I think this is a key reality of working in open source. We connect with people all over the world, our communication is mediated and facilitated with technology, and we bring very different experiences to those interactions. It’s really shared purpose, and a willingness to achieve something together that drive the interactions. I find it constantly affirming and surprising how little actually knowing someone matters when you have a job to do together. We learn about each other along the way though, and that’s a real joy. Also? Don’t talk to me about time zones.

How does your participation in the open source community ignite your interest in conflict resolution?

GL: When people are passionate, conflict is almost inevitable, and people who work in open source are nothing if not passionate. Furthermore, in open source there aren't any external entities to whom we can turn to "fix it," like HR departments, the law or the government. It's just us, and we have to learn to creatively resolve conflict in ways that work for us, rather than tear us apart.

DB: What Gina said really sums it up perfectly. I guess I've come to appreciate the potential of conflict, and am keen to explore ways for us to acknowledge its presence in our communities in a more healthy way. I really think this goes beyond open source though. There are other groups, communities, and industries who have "solved" some of these issues in ways we can learn from. I also suspect, that just as the open source way has disrupted traditional models for software development and distribution, there's potential for our communities to find new ways to address the issues, challenges and opportunities presented by conflict.

Without giving away all of the tips in your talk, walk me through what bad versus good conflict resolution looks like.

GL: I think that one of the things that's key in conflict resolution is bringing compassion to the table. This is especially hard, I believe, when we aren't face-to-face. If you can see that you've made me cry, you might stop and think about the things you're saying. However, when things are time-shifted and geo-separated, it's often hard to remember that there are real people on the other end of the conversation and that those people deserve compassion.

DB: Yeah, absolutely. Compassion is a critical success factor for constructive conflict resolution. The other one? Respect. Respecting your opponent is important in the martial arts. I think we should take that idea, and apply it to our community disagreements too. My view is we need to harness conflict as a power source. Let's use the deep, underlying passion or frustration of conflict, and transform it into focused energy for change. When people are cranky, there’s usually a good reason why. Perhaps they're just tired or hungry or having a bad day? In which case, understanding, compassion, sleep, or food is all that’s needed. Or maybe there's a real problem we need to address which will improve the situation for everyone.

How do you keep your tips for conflict resolution engaging enough to resonate with the engineering community?

GL: Cat pictures? Also, cartoons help.

Seriously, one of the problems I see around this issue is that the people who go to these talks are often "the choir," as in, "We’re talking to the choir." They are the people who are interested in conflict resolution and want to learn more, so for them, it's a matter of presenting good information that helps solve problems. The challenge, I think, is how we get this message out to the people who don't want to hear it or who don't think they need to hear it. I'm not sure how to do that, and am open to suggestions!

DB: This is a very good question. I really don't know the answer here either. I do agree with Gina, though, that too often we're preaching to the already-converted choir. This is kind of "woo-woo" stuff. It's easily dismissed by task-oriented people who just want to get on with the job. Some people believe the best way to deal with conflict is to avoid it entirely. Talking about feelings and emotions, and then dealing with those things is not in everyone’s skill set. My biggest concern, though, is that this is real work. I feel too many people in our community either don’t value it, or don't recognize it as real work.

Gina, I'm still pretty fascinated by the work you are doing with universities to help them get more involved in open source projects. Tell me more about what you are doing and why is it important?

GL: Our program at Red Hat, University Outreach, has several components, but the one that I am the most involved in aims to get more university-level instructors incorporating open source into their classrooms. We’re using a number of methods to achieve that goal, including:

• educating instructors about the value of teaching open source;
• creating open source-based instructional materials that can be incorporated directly into classrooms; and
• co-sponsoring, along with the National Science Foundation, intensive workshops, called POSSE (Professors Open Source Software Experience), where instructors can really learn the ins and outs of open source.

It's important because most computer science undergraduates don't know what open source is or understand how it works. I've spent a lot of time talking to students and teachers in the past year, and it's been really surprising to me that so few students "get" open source software and so few teachers even mention it, much less teach it. This is a problem because Linux developers are getting older and our industry needs more new developers—and younger developers—to thrive and grow.

I spent some time exploring Sugarlabs (an educational tool that is focused on collaboration) after bumping into the reference on Donna's blog. What got you involved in the project?

DL: Sugarlabs came out of the One Laptop per Child project. When that was first announced, I thought: "This is going to change the world." I was incredibly excited about it. And I think it did change the world. Before the "hundred dollar laptop," these capable, portable devices were completely beyond the reach of most of the global population. Shortly after, we got netbooks, which redefined the laptop market.

I’ve been involved with the technology education community here in Victoria, my home state, since the turn of the century, so I’ve been very interested in supporting educators who use, and teach with technology. Sugar was a brand new interface for learning, with lots of great thinking "under the hood," if you like. Sadly, I’ve lost touch with where things are at with the Sugar project. I’d like to reconnect with what's going on there these days.

Tell me one fun factoid that people should know about you before walking into your talk at OSCON?

GL: Fun factoid: I have taken flying trapeze lessons and ridden in a zeppelin.

DB: Really, Gina? That’s awesome. We should run away and join a circus. I can juggle! See what I mean about learning about each other along the way? See you in Portland!

This article is part of the Speaker Interview Series for OSCON 2015. OSCON is everything open source—the full stack, with all of the languages, tools, frameworks, and best practices that you use in your work every day. OSCON 2015 will be held July 20-24 in Portland, Oregon..