Stay for the community
This article was originally a keynote presentation at the Pacific Northwest Drupal Summit in October of 2014. I’ve tried my best to capture the spirit and feel of the talk in an article, but the original talk had a short video embedded in it which is important to illustrate a key point. When you encounter this video, please take the time to watch it before moving on.
The genesis of this article started back in 2010, when I was in a discussion with a member of the Drupal community about an issue that was a hot topic at the time: Expand options in the “Gender” profile field.
His very strong stance in this discussion was that someone’s gender identity has nothing to do with Drupal the software or the development thereof, and thus has no place being discussed on drupal.org. I countered by pointing out to him the very first words on front page of that very site:
My point was that “Stay for the community” is not just something we say to feel good about ourselves, it is a statement that we as human beings work together, under a shared set of beliefs and values. My belief was (and is) that forcing “the community” into a purely technical framework is not only an exercise in futility but actively counterproductive.
Ever since, that thought has lodged in my mind, and it’s something I’ve had difficulty getting rid of. While we did eventually expand the gender options field (after several more discussions), even participation in purely technical political efforts like The Day We Fight Back has generated controversy. What does “Stay For The Community” really mean? What does “The Community” even really mean? Not as a group, obviously it encompasses those who help to build Drupal in all the myriad ways they do it. But what does it say about our goals, our values? Even more, does it really need to say anything about our goals and values? Is it enough for it to just be the people who build Drupal and let the rest go by the wayside?
We have spent the vast majority of our time together largely operating under that last banner, but that doesn’t mean that we have no shared values. It just means that they largely go unstated. Which is funny because I think if I were to take a poll of the people reading this, we’d find that on a lot of these social and organizational issues our heads are pretty well aligned. Here are some examples.
- Do you think the diversity of our community is important?
- Would you volunteer for a community if you are not being treated with civility and respect?
- Have you experienced, or know someone who has experienced, burnout? Did you think it was fun either as the person going through burnout, or as the person supporting someone going through burnout?
I think in general the Drupal community, like most people reading this, is pretty well aligned on these kinds of principles. The “funny” thing is that a lot of our structural underpinnings completely undermine them, and that’s what I’d like to get into today. Because I feel like the conflict between these principles we generally agree on and the reality of how the community is structured causes a lot of cognitive dissonance, and this has been responsible for much of conflict in the last few years.
The Tyranny Of Structurelessness
At Twin Cities DrupalCamp, Larry Garfield talked about how one of the biggest challenges to Drupal right now is our lack of formalized structure, and how this hamstrings technical decision-making. One of the things I pointed out to him is that in order to create a new structure we would have to tear down our existing one. He kind of looked at me quizzically, because outside of Dries, Drupal has no real structure right? I know that on paper that is how it looks, but its really not the case.
Jo Freeman is an activist who was heavily involved in the civil rights and women’s liberation movements in the 60s. She actually created a newsletter called “Voice of the women’s liberation movement” which gave the new movement its name. In 1970 she gave a speech, later translated into a paper, called The Tyranny Of Structurelessness. If you’ve talked to me in the last five years you’ve probably heard me mention it. The talk describes her experiences in the women’s rights movement, but it is equally applicable to Drupal and many other open source projects.
In this paper, Freeman describes how the apparent lack of structure in an organization often masks an informal structure that is all the more insidious in its lack of transparency and the denial of its existence. It is important to note that these groups do not form with the intention of holding power, instead it is typically just groups of friends, people who have the same values and perspectives. Also these groups are not inevitably bad, even heavily structured organizations create informal unstructured groups. However only fundamentally “unstructured” groups become governed by these invisible groups, which is a really important difference.
One of the biggest problems in these groups is a lack of transparent decision-making. Groups in Drupal talk to each other in all sorts of places — IRC chats, in real life, informal hangouts of topic experts — and these discussions naturally lead to decisions and other forms of guidance. This has a tendency to disempower the people who are not “elites”.
“Because people are friends, because they usually share the same values and orientations, Because they talk to each other socially and consult with each other when common decisions have to be made, the people involved in these networks have more power in the group than those who don’t. And it is a rare group that does not establish some informal networks of communication through the friends that are made in it.” — Jo Freeman, The Tyranny Of Structurelessness
These invisible structures also disempower new contributors. For example, they may not realize they are dealing with empowered individuals in the issue queue, who often have more influence on the discussion than they realize. It can be demoralizing for them when they see other people’s work getting in with less scrutiny than their own, or with more assumptions about the quality of the work. This can be even worse when these people have community standards applied in a different manner than other contributors.
It’s worth noting that the paper is written from the perspective of someone advocating for a more democratic process, and I’m not sure that would be any better for an us than what we have now. It is also a little dated. However, whenever I read it, I am struck by how much of it rings true for us in our project.
This struggle around structure or the lack of it has been plainly evident in the past several years. In the Drupal 8 cycle, Dries attempted to add a very light element of structure on core dev in the initiative leads, and even that was incredibly controversial. I was the first lead to be named, so I got a lot of the early heat around this. When I began discussing the idea with Dries, I had very little core experience. I had about 30 patches in the Drupal 7 cycle, and they were mostly documentation. So I guess I shouldn’t have been surprised when my appointment was so controversial that at least one person in the community tried to have it killed before it was even announced. The nomination of David Strauss as my co-lead was done in order to appease this person, and to this day I don’t know who it was. Even for someone of my status, a power structure existed to give this person access to Dries and his decision-making process, but with zero transparency to me.
Thereafter, as the first initiative leads were named, many cries came from powerful contributors that they should have an initiative. After all they built Drupal. They wrote the most patches, so why shouldn’t they lead? This despite the fact that from the beginning Dries had made it clear that initiative leads may not even be coders at all, because the skills central to leading a project often focus more on soft skills. This is such a mindblowing concept to many in our community, structured the way it is, that a lot of longtime core contributors still have a hard time comprehending it.
So, if we do in fact have an invisible structure at work in our project, what is it?
Time
Those who spend the most hours in the queue, and get in the most patches, gain the rewards of participation. This is inherent in the name we use to describe our system of governance — the do-ocracy. Those who do gain influence and a voice in the project. On paper this sounds like a great plan, right? Why would you give a voice to those who aren’t taking part? But unfortunately it has some really terrible side effects, and these have only increased as our community has grown.
One effect is that in order to put forth time in the project, you actually have to have it, and as the number of participants in the project has grown, so has the amount of time needed to become more well known in the community. A few weeks ago, Drupal 8 core maintainer Angie Byron asked the question on Twitter “If you’re a developer, and you aren’t fixing #Drupal 8 critical bugs, care to share why?”A huge number of the responses focused on the amount of time and energy needed to get even the most seemingly simple issues in, as well as the problems of transparency in the process.
I know that when I started my actual work in the Drupal 8 Configuration Management Initiative (CMI for short), the biggest problem I found in the current atmosphere was that in order to effectively manage the issue queue, I must devote at least 25% more time than my most active contributors. Otherwise, they become the de-facto leaders of the project in question. Given that the most active contributors in CMI easily put 60+ hours a week into the project, that was a hill that was essentially impossible for me to climb if I wanted to have any kind of life outside the project at all. Of course many people respond to this by simply abandoning more and more of their life outside the project, until it essentially becomes their lives. Thus the do-ocracy becomes self-perpetuating.
Another problem is that this ends up favoring a very narrow sector of the populace, at great cost to the project’s diversity. Ashe Dryden has written an article “The Ethics of Unpaid Labor and the OSS Community” which has some fantastic data around this. As an example, women, who are most often tasked with caregiving in the home, are going to in general end up having far less time to participate than men. For women of color the situation is even worse. Their salaries are on average 55% of white men’s salaries, making it more likely that they have to work more hours in order to make up the gap. Poorer people tend to live farther away from city centers, meaning they have to spend more time commuting. Since the vast majority of core work is done unpaid, this leaves a pretty brutal hill to climb for those with responsibilities outside the project.
One more side effect of the do-acracy is that as you put more time into the project, you become more valuable to the project. Drupal contribution is a classic long tail, the top 10 participants are in-part responsible for over 20% of the patches committed to Drupal 8. In fact the top two participants are responsible for almost 9% of the patches alone. Obviously these are people you need if you want the project to move forward. As shown earlier, these people also naturally become part of the friend network of the community. This is the natural way for any group of people of any size. However this also leads to the horrible situation that when one of these individuals starts behaving in a bullying or abusive manner, there are numerous disincentives to speaking up against it or, if the problem is severe enough, ejecting them from the community. Their productivity makes them immensely valuable, and their friendships make it less likely that others at the same level of contrubution will be willing to speak up against them.
This is, in my opinion, one of the worst current effects of our do-ocratic structure. It is yet another way that we alienate new contributors, especially if they get called out for behaviors they see empowered contributors exhibiting constantly. Also, you know, being a jerk is bad, but it’s even worse than you think.
Bad Apples
In 2006 Will Phelps did a study called “How, when, and Why Bad
Apples Spoil the Barrel” in which he took a group of smart, motivated people and asked them to perform a task together as a group, and if they succeeded they would get $100 each. A big motivation to complete the task for poor college kids. The interesting part is that in some of the groups, he inserted an actor to be a disruptor to the group — a bad apple — to see what that person’s effects were. There were three potential personality types the bad apple could take.
- Slackers, who take a “free ride” from the group. They don’t do any of the work but partake in the rewards of completion. In this scenario, the actor would do things like put their feet up and text while everyone else was working, or pull out a sandwich and start eating.
- Depressives, who constantly express pessimism and cynicism towards the task. They complain that it is unenjoyable, that they will never succeed, and that the whole effort is pointless.
- Jerks, who make mean remarks, curse at people, or publicly embarrass participants. They say very agressive things like “Are you kidding me?” or “Have you ever done work like this before?”
Conventional wisdom for years had said that group dynamics can overcome bad individuals. However what this study found is that, in opposition to all prior theory on group dynamics, groups do not overcome bad apples. In fact the truth is actually worse — not only are those groups less effective, but they are far more likely to begin exhibiting the characteristics of the bad apple themselves. And not just in response to the bad apple, but they would do so to each other. The fact is that the best predictor of how any group performs is not how great your best member is, but how terrible your worst member is. Phelps was interviewed on an episode of This American Life called “Ruining It For The Rest Of Us” that is worth seeking out.
This manifests itself in core development in a lot of different ways. Obviously there are jerk-like abusive behaviors that are relatively easy to spot. However as an initiative lead, I encountered a lot of other bad apple behavior that was a lot more subtle. As an example, I would be working on an issue and a well-respected member of the core community would post a new version of the patch, completely rewritten, with no outside discussion prior to the posting. Discussion would then continue around the new patch, after all it was posted by someone with a great deal of karma in the do-acracy, so it must be worthy of everyone’s attention. At the same time that person gets to express their lack of respect for my position, despite my leadership in name.
This is an extremely difficult problem to solve. If you call out the contributor, they can easily feign ignorance, and talk about how it is all about code quality. If you don’t, it erodes what little authority you had and transfers it to the empowered contributor. Combine this with our discussion earlier about trying to keep up with the time these contributors put in, and you find yourself in an almost unwinnable situation.
So What Now?
At the beginning of this talk I talked about the values we have as a community, and I’ve outlined a lot of the systemic and structural issues in Drupal that work at odds to those values. So what can we actually do about it?
First off, I want to point out that I’m not trying to make the point that the community should structurally change. I actually believe that any fundamental shift in our community’s structure wouldn’t really be Drupal anymore. However our current structure does have negative consequences, and bringing them out into the open is the first step to figuring out how to address them.
There was one thing I left out when I discussed Will Phelps’ study about bad apples: out of all the dozens of times the test was run, there was one single group that did manage to overcome the influence of the bad actor. It had a guy in it who was particularly good at diffusing conflict by going around, asking questions, soliciting opinions, and listening. It turned out this person was the son of a diplomat, and had picked up many of those skills throughout his life.
Over the life of Drupal, Angie Byron has been the main person who has played this role for our community, but unfortunately as the project has grown, her ability (and desire) to do this has diminished significantly. As the saying goes “Webchick doesn’t scale”. It would be extremely worthwhile for us as a community to encourage and nourish these skills in others, or possibly recruit people into the project already well trained in those skills. We also need to find a way to acknowledge and publicize their value to the project. This has long been a problem with non-technical contributors to Drupal, but it is key to recruiting and keeping them in the project. Gabor Hojtsy, the lead for the Multilingual Initiative for Drupal 8, recently wrote an excellent blog post about leadership which has a lot of insight how he managed this for his initiative.
I’ve also talked a lot about how structurelessness disempowers new contributors with its lack of transparency. The core mentoring group is something we already have in place, and to some extent it already works to help new contributors navigate the dark hallways of core development. Making this more intentional and structured could help alleviate these symptoms even more. In fact the core mentoring process is a good example of how you can take a piece of development that has been totally unstructured and build some formality around it. They organize sprints with specific people taking the lead, have assigned roles at events, and have grown to be enormously successful within the systemic problems of core development.
While these are good and important systemic responses, I’d also like to turn things around and look at them from a different angle. At the beginning of this article, I didn’t ask “the community” for their values, I asked you. I admit I stacked the deck a bit with the questions, but the point remains that for all my talk about “the community” the truth is that “the community” doesn’t do anything. We individually do things, and we individually have our own values. I think this is a pretty important lesson to take with you. I did a talk at DrupalCon Chicago called “A Shot In The Arm” in which I described how it wasn’t “the community” that got me into Drupal, it was people, individuals who treated me with respect and dignity and encouraged me to try new things and make a place for myself in Drupal, even though some of my ideas were kind of whacked out and weird. Individuals who represented the values that they felt the “community” stood for.
If you look at Drupal’s history, major change (technical or not) rarely gets pushed down from the top. Change bubbles up from us, and when we are ready, Dries puts the changes into place. This holds true from the simplest core patches to architectural decisions to implementing a code of conduct to infrastructure choices like what version control system to use.
The community is what we make it. If you see behavior you don’t like, call it out. We have a code of conduct, use it. I know exactly how hard that can be, especially when we’re all friends and there is often pressure (spoken or unspoken) not to increase drama. But if we want to see change in our community, then we need to represent that change and make it known. We have seen this in the last several years around our events, and I think it has had a fantastic impact. The road was painful, but I would argue that DrupalCons are now far more inviting and inclusive than they have ever been in the past. This happened because individuals were brave enough to open the discussion, share their own experiences, and work to make the change they wanted to see. I’d love to see this kind of activism move into the core development process. At the end of the day, how we treat each other, how we work together, is so much more important than what we build. Eventually the Drupal bubble will burst, some other hot shit will come along and render us useless, but these experiences and friendships are the things we will take with us throughout our lives.
The Job Will Not Save You
Its funny because for all the time we spend talking about Drupal the software, I really couldn’t give a shit about Drupal the software. I didn’t get involved with Drupal because I wanted to build the best CMS in the entire world. I got involved because of Angie and Jeff Eaton and Boris Mann and all the others who blew my mind when I first got introduced to the project. I got involved because of the amazing people I met, and what they taught me, and what I thought I could pass on to others. I never really cared all that much about what we built, I mean sure I cared about doing good work, but really I cared far more about who I worked with that anything else. I wanted to be inspired, I wanted to learn … not about software, but about the amazing and diverse community of people that surrounds me. Drupal the software has provided me a career, but Drupal the community has truly changed my life.
After I became initiative lead though, after working in the core queues for a couple years, all the issues I’ve talked about today started taking over, and as I became more and more deeply involved I also became more and more deeply disillusioned. Yet I still felt like leaving would be letting the community down. That is one of the darker things that happens, usually totally unintentionally, with passionate volunteer-drive communities of all kinds. They can use your own passions to their own interests, regardless of the personal cost.
Sometime during the tail end of my participation in the CMI intiative, I was pretty deep in the weeds, and for my birthday I took a few days off and went to LA to see a couple bands play. During this trip I spent a lot of time watching The Wire, a show which is truly profound about life and the world, and there was a scene that hit me so hard, it seriously blew my mind.
I have spent over two decades of my life trying to find the meaning in my life through my work, turning every serious hobby I’ve ever had into a job. Pinball, music, internet… and so was it also with Drupal, and what did I expect to find from it? Even if there was a parade or a gold watch, what then? Drupal 9? Drupal 10? I had spent two entire years of my life traveling the world and while I had spent a lot of time with many of my favorite people, I realized that the real reason it was so easy is because I had no roots anywhere. I felt homeless and lost, and traveling the world is easy when you don’t have anything to come home to.
Life.
The shit that happens while you’re waiting for moments that never come.
So the last thing I want to leave you with is that I encourage all of you to cling to life. Contribute as and how you wish, find the value for yourself in the software and the community, but don’t get lost. You may think Drupal will fall apart without you, but if the only way that Drupal can survive is by burning out its contributors then it doesn’t deserve to exist. For all of our talk about how Drupal will change the world, if it comes at that kind of human cost then I would rather watch it burn. Take care of yourself and always remember
Drupal exists for us, and not vice versa.
Drupal doesn’t change the world.
You do.
