a theory on tech community drama

I’ve been following and trying not to participate in the recent Node drama, wherein an innocent PR evolved into a battle of egos on GitHub and resulted in a very direct statement from Joyent and a large amount of hand-wringing from people offended by that statement. I’d like to propose a theory on why this kind of thing happens in the first place, and why this is not the last time it will happen to Node. Let’s reverse-engineer this fucker and maybe we can stop having the same conversation about vague inclusivity over and over again and talk instead about how exclusivity becomes the assumption.

This drama starts, at least in my mind, not with the modest and helpful PR, but with the reaction of a maintainer of the project (libuv) declaring it too trivial for him to be interested in. So here is the first problem, and it’s one Joyent mentions in their response: people who have admin rights on projects based on their coding skills, not their ability to lead or deal nicely with other people. I do not maintain any big open source projects, but in talking to people who do it’s become my understanding that the bulk of the work is sifting through issues and pull requests, not actually coding. The former is the thing they consider hardest, the thing that burns them out, their most overwhelming responsibility. So it makes no sense to me that such a role would be given to someone who deals with other people badly. And I want to clarify, that’s all I’m reading into this. I honestly don’t know (or care) if Ben Noordhuis is a sexist. I do know and care that he very blatantly let his ego drive his decision-making here, which makes him not a good leader.

But it sounds completely ridiculous to suggest that people have admin rights on open source projects because of their skill in dealing with people instead of their skill in coding, right? I know it must, because there are basically zero examples of anything to the contrary. It’s an absurd kind of bloody monarchy where the only way to lead an open source project is to be the person who wrote the original code or to defeat the original author in battle, proving your worthiness. Via code, obviously. And so all around us we have a very clear message that code is all that matters, and whoever codes best is automatically right in all things. So we can’t really be surprised when this kind of shit happens.

(I want to take a moment to note that Node does have some very good leaders who are skilled at dealing nicely with people, but that standard is less evident when you consider those beyond the most visible folks.)

Is it possible to change the culture of open source in this way? I really have no idea. Well no, that’s not true. My low participation in open source is due to my sense that it’s most likely not possible. But maybe I’m wrong. I’d like to be. What I suspect, though, is that open source rejects the idea of “management”, and having people making decisions who have not been vetted by the infallible meritocracy of holy code sounds too close to being managed for comfort. Of course, anyone who’s been promoted to or worked under a developer-cum-manager might be able to tell you how they found they actually needed a manager who knew how to take care of humans, but nevermind all that. We don’t need no parents, we’re open source, we came to party.

Of course, if this dustup could have been guaranteed to be avoided, the how is real fucking obvious. The original PR changed male pronouns to neutral ones, so as not to exclude people who don’t identify as men. A non-male maintainer would probably have accepted that immediately (and been a bit embarrassed). That’s a silly hypothetical, though, because under our current system this non-male maintainer would have to be pretty heavily involved to become a maintainer and thus would have gotten to the pronouns at issue before anyone else even saw them. They might even have been the originator of said pronouns, meaning they’d be pretty likely to start off gender-neutral and stay that way. Which is to say: because open source is so non-diverse, and presents itself as hostile and obsessed with meritocracy to the point that it drives people who might add to its diversity away, it will always be cleaning up the artifacts of that imbalance after the fact, once people have noticed and drawn conclusions, and once those privileged enough to succeed under the meritocratic system have gotten all fucking defensive about it.

“Always” might sound like a pretty strong word to use, but it’s what I believe. Well-intentioned (and grammatically correct) though it may be, changing pronouns has very little impact on inclusivity. When you’re starting from a default position of exclusivity, when people automatically associate you with the tone-deaf cringefests that are one of open source’s worst problems, when people see your community and your leadership and find very few diverse participants, when your actions don’t illustrate how people can play a role if they won’t prove themselves better coders than those already involved, hanging up a sign saying “no one is disallowed” is not going to be enough. Saying you want to be inclusive does not create a culture of inclusivity. Those who it might hope to include will be smart enough to know that if they accept that invitation, it will become their burden to deal with those already included who are quite happy to enforce a culture of implicit exclusivity. If you want to be inclusive, find the people you want to include and fucking include them. Don’t wait for them to “man up” and make pull requests or submit to your CfP or whatever; only the most belligerent are going to bother to challenge the mixed message in “we want you here, please fight your way in, and can you pick up some ice on the way”.

So those two things are how I think Node got here – emphasizing code skill above all else in building community, and relying on that broken meritocracy to deliver diversity. I see a lot of hearts in the right places, but I also see a lot of defensive and self-righteous anger. I don’t see anyone addressing those problems I’d consider fundamental, so that’s why I think this will happen again.

Earlier, Bryan Cantrill, author of Joyent’s response, tweeted this about it: “And given the haters I’ve seen today, I shudder to think of the hate that would have been unloaded on me were I female.” I thought that was funny, because in a world where a woman held Mr. Cantrill’s position at Joyent, this probably never would have come up (because see above, not due to any deficiency on his part). We live pretty far away from such a world, though.

Tags:

4 Responses to “a theory on tech community drama”

  1. Vitorio Says:

    I think I disagree on two points.

    1: “What I suspect, though, is that open source rejects the idea of ‘management’, and having people making decisions who have not been vetted by the infallible meritocracy of holy code sounds too close to being managed for comfort.”

    Open source as a broadly-generalized culture might, but perhaps it comes, not from individuals bristling at being managed, but individuals bristling at being told they’re wrong about anything. Individuals who are told they’re wrong all day long, maybe all life long. Individuals who grew up being ostracized socially, they didn’t become well-rounded in college, and now they’re under-appreciated at work and have trouble socializing outside a small group of people and only with a drink in front of them.

    The open source projects they run or contribute to are their identity, now. Statistically, as a group of intelligent, creative-class, white males, they’re part of a privileged group, but in their own lives, rejecting that commit is the only assertive action they’ll take in their lives today. The myth of open source, the one group that accepted them as they were, is that code is law, so they reject the commit as inefficient (either of code or of their development time), in deference to the prima facie culture. That they don’t examine it is no different than someone not examining the religion they were raised with, and criticizing them is no different than a Catholic arguing with a Protestant. It’s not an argument you can win, because it’s against their identity, and few people are capable of deconstructing that, and fewer still desire to.

    2: “My low participation in open source is due to my sense that it’s most likely not possible.” and “Which is to say: because open source is so non-diverse, and presents itself as hostile and obsessed with meritocracy to the point that it drives people who might add to its diversity away, it will always be cleaning up the artifacts of that imbalance after the fact, once people have noticed and drawn conclusions, and once those privileged enough to succeed under the meritocratic system have gotten all fucking defensive about it.”

    Coming out of my first point, if the problem is with individual people, then you’re right, you can’t change it, because you can’t change other people.

    But you can be the diversity and run a project the way you think it should be run. I imagine it’s sort of like this blog post, but replace “blog about code” with “run an open source project” in your head: http://www.garann.com/dev/2013/how-to-blog-about-code-and-give-zero-fucks/

    (I think Bryan Cantrill is wrong, too: I think Isaac Schlueter does have the lever of taking away Ben Noordhuis’ commit bit, and demonstrating that while code is important, maturity and social skills are, too. Maybe that’d cause Noordhuis to start up a boys-only Node.js fork, and maybe that’d make it really easy to learn who to not work with or invite to conferences because they’ll probably try to grab my ass.)

    I think by being the diversity you want to see, by making a warm, inviting community important, your project can see broad benefits, like being able to track the number of people who have committed code for their first time ever as a success metric: http://smarterware.org/7550/designers-women-and-hostility-in-open-source

  2. garann Says:

    @Vito – Ok, honestly, I’m tempted to agree with your first point. I wonder if that’s not a dangerous kind of nerd essentialism, though, where we assume developers will be these frustrated, ineffectual people and then excuse our behavior when we live up to that stereotype.

    And yeah, your second point would obviously help provide a solution. It’s easier said than done, though. You have to be able to not only code something worthwhile and lead a responsible team of contributors but to do the marketing that makes any of it matter.

  3. Oncle Tom Says:

    You have a good analysis of the situation. Meritocracy through code.

    Although I’d like to counterbalance some points: this is not Node specific, this is computing/programming specific. Well, this is specific to every community run by an homogeneous panel of leaders. This can be either as good (when leaders are caring and listening) as bad (this specific case).

    Intentions are important. Some don’t realise the impact of the words in the consciousness of others. Some deliberately want to hurt, for whatever reason.

    The good thing in this conflict is how the governance of Node is handled, and how the I inclusiveness of a voluntary initiative is envisioned.

    People make mistakes. The problem lies in how it is addressed, by both tiers, offended and offenders.

    Splitting for a new group/consortium is also childish as it will not solve the root problem. It just adds a new layer of complexity and authority.

    npm is brilliant. Many npm committers are open source enthusiasts who might feel ashamed of this situation, whereas they are male or female.

  4. Vitorio Says:

    @garann, I think you’re right that the “frustrated, ineffectual” part is probably too broad a generalization, and that it’s not an excuse on anyone’s part.

    But, as an aspect of a person’s identity, I think it means we need to be empathetic about why they hold those beliefs, because that means dealing with it is more complicated than a “meritocratic” argument, ostracization (which may make it worse), or righteous bullying.