Nick Desaulniers is collecting brief statements from people who do open-source about what it means to them, as a text file extended via Github pull requests. You can add your own by forking the repository and submitting a pull request. I’d love to see more additions from people in communities that are marginalized in open-source development (and in tech generally).
This is an expanded version of a comment I wrote to a woman who doesn’t work in software and was wondering what was wrong with using “he” as a default pronoun to refer to a programmer whose identity is unknown, since after all, most programmers are male.
Okay, suppose I was a woman, and somebody said this to me. The ‘he’ would be one more tiny reminder, to me, that everyone in my field assumes that people like me don’t do computer science. That would make me feel just a tiny bit more discouraged and, maybe, eventually I would look for a different field, one where I don’t have to prove I belong.
So when somebody makes this choice — “most programmers are male, so I’ll use ‘he'” — their language ceases to just describe reality. It creates reality, by reminding me that I don’t belong. The ‘he’ is a self-fulfilling prophecy. I’m not saying that hypothetical female me, or any woman, would change careers over one dodgy pronoun. It’s the cumulative effect of many microaggressions that has a disparate impact on women in a male-dominated field.
In software, we literally use programming languages to make things happen, so I am constantly disappointed when other people in my field fail to understand how their language doesn’t just describe reality, but also constructs it. In general, the structure of the English language (and other natural languages in which “he” is often used to refer to a generic person) creates a reality in which people are men, and men are people. A man can appear wherever a person is expected, but a woman cannot appear wherever a generic person is expected; women are second-class. Just as if a particular programming language is too awkward to write code in, we can fork it and modify its syntax and semantics, or even create a new language, we do not have to accept this aspect of English. We can choose to use language in a way that reflects what we believe, instead of using it to uphold traditions we find repugnant.
A related example is when somebody uses “guys” to refer to a group of programmers: either in the second person (“hi guys, I have a question”) or the third (“oh, the compiler guys at Apple will fix that”). I think this usage implies even more strongly that women ought to be glad to be misgendered, since using “ladies” to address a mixed group would always seem bizarre and, in some circles, would be taken as very insulting.
It costs nothing to say “folks”, “y’all”, “engineers”, or “team” instead of guys. And yet, some people vociferously defend their usage of “guys” in this manner. The benefits of using a gender-neutral collective noun are, through ripple effects, potentially huge. Every time a woman or genderqueer person (especially one who’s just starting out) hears someone acknowledge that they know that not all programmers are guys, it’s a microprogression: a tiny bit of encouragement. I can’t think of what the benefits of continuing to use guys might be, unless you think it’s beneficial to continue driving women out of your field.
Margaret Burnett once described what it’s like to be a woman studying computer science something like this: “Imagine you walk into a classroom and everybody else is three and a half feet tall. You’re the only one who’s six feet tall. Would you feel like you ought to be there?” Using “he” or “guys” to refer to programmers of unknown gender creates that same kind of space online — a space where everybody else is three and a half feet tall and you’re not, and you’re suddenly reminded of that. It takes a place that was inclusive and — for no particularly good reason — makes some people uncomfortable just being there at all.
Especially when talking in a public forum online, you usually don’t know who your entire audience is, and you usually don’t know if — at this specific moment — you could be the difference between reminding someone of the extra work they have to do (just because of their gender) to prove that they’re accepted and respected as a programmer, and reminding them that they are just as likely to be a good programmer as anyone else is.
I don’t have the hard data at hand, but my impression of the field of computer science that I did my graduate work in and continue to apply in my career — programming languages — is that it’s unusually homogeneous, even for computer science. I’ve written before on this blog about some of the consequences of gender inequality in programming languages research; things are not much less dire with respect to racial and cultural diversity.
One upcoming opportunity to get help with getting started in the field, for both graduate students and serious undergraduate students, is the Programming Languages Mentoring Workshop (PLMW). In 2014, PLMW will be co-located with POPL (the ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages), in San Diego, California, USA in January. The deadline to register for PLMW is December 10, and the ACM is making some funding available for students to attend PLMW and POPL, including travel costs.
POPL is probably the most prestigious conference on programming language theory, and I can say from experience that many (if not most) of the talks at POPL tend to be not exactly geared to a novice audience. When I attended POPL 2008 in San Francisco, one of the custodians at the hotel where the conference was taking place asked me, out of the blue, “What’s this conference about? With most conferences that happen here, I can figure out what they’re talking about, but with this one I have no idea.”
So attending PLMW looks like a great opportunity to be reminded that you’re not the only one who doesn’t already know everything. I just wish it had existed back in the early 2000s when I could have benefited a lot from it!
A big initiative for those interested in getting involved in open source is happening right now: the GNOME Outreach Program for Women (OPW). OPW is accepting applications from now until November 11, 2013 for the program that begins December 10, 2013 and ends March 10, 2014.
If you’re interested in getting involved in open source, but don’t know where to begin, consider applying for OPW. OPW internships are paid, full-time, and allow you to work from home (there is also funding for potential travel to visit your sponsoring organization for a short period of time). OPW is inclusive: all women, including cis women and trans women; as well as anybody who was assigned female at birth; and anybody who identifies as genderqueer, genderfree, or genderfluid (regardless of the sex they were assigned at birth) are encouraged to apply. OPW is open to students and non-students alike (as long as you’re 18 years old or older as of December 10, 2013) and is open to people with any level of computing or software experience, so long as they’re relative newcomers to open-source development.
As the OPW page explains, “The internships offered are not limited to coding, but include user experience design, graphic design, documentation, web development, marketing, translation and other types of tasks needed to sustain a FOSS project.”
Not that I’m biased or anything, but since I work for Mozilla, I’d like to call attention to our OPW projects. Several other organizations are participating as well — Debian, Fedora, GNOME, the Linux Kernel, OpenStack, Wikimedia, and Xen — and if you’re involved with one or more of those, you’re welcome to toot your project’s horn in the comments!
This is the third time that Mozilla is participating in OPW, but the first time that Mozilla Research is participating. Because I work for Mozilla Research, on Rust, I’m excited that we’re accepting one intern each for Rust (a new systems programming language; most of the internships focus on libraries and tools for it) and Servo (a prototype parallel Web browser engine implemented in Rust), both of which are projects that are under the umbrella of Mozilla Research. A third Mozilla opportunity is to work on community building with Larissa Shapiro, Mozilla’s Head of Contributor Development. For the full scoop on all of these projects, see Mozilla’s OPW page for December 2013. I’m coordinating Mozilla’s involvement with OPW, as well as coordinating mentorship for the Rust projects; Lars Bergstrom is coordinating the Servo projects.
If you’re not sure whether you should apply to OPW, then you’re probably somebody who should apply. But as the OPW page says, the application process is collaborative, so it’s a good idea to talk over email with the coordinator for the project you’re interested in to find out more about what they’re looking for in applicants. As always, it’s best to show that you’ve done your homework and ask specific, focused questions so as to help the potential mentor help you.
If you’re not in the OPW audience, you can still help! Please advertise these programs to students and women who might not otherwise see them. You can put up posters where people who are marginalized in open-source communities will see them; help encourage people who are enthusiastic about one of the projects but might be too nervous to submit an application; and help connect the same people directly to projects whenever you can.
I shamelessly ripped off portions of this post from Terri’s OPW/GSOC post from back in April.
By now, many of you have probably read Sarah Sharp’s blog post about civility in the Linux kernel community as well as her followup post about it. As an experiment, Sharp decided to allow unmoderated comments on her original post, which has 284 comments as of this writing.
I’m not going to go re-read all of those comments, because I would rather remove my own appendix with a rusty spork. Rather, I just want to make one observation. Again, I’m not going to back up this observation by reference to specific comments, since they are terrible.
A frequent response when people point out that Linus Torvalds (or another prominent open-source leader known for abrasiveness) is rude to people is, “Yeah, well, he’s a jerk, but he gets things done.”
Now, there’s certainly no denying that GNU/Linux is a successful project. However, it would be a logical error to conclude from its success that it’s inconceivable that the same project could have been more successful if its members — and especially leaders — were committed to treating each other with respect.
For example, there’s reason to believe that verbal abuse is more likely to turn off women contributors than men. This is certainly not universal (there are plenty of women who are happy to respond to rudeness in kind, as well as shy and sensitive men). I also don’t believe it’s due to any sort of deep biological truth; more so due to the ways that men and women are often trained into different communication patterns, and rewarded for conforming. When I say “women”, by the way, that includes all women, because even women who weren’t assigned female at birth frequently know which social messages are meant for them, and internalize them starting from an early age. And if you are driving away roughly half the population from your project, you’re driving away half of all potential contributors for no particular reason.
I am certainly not the first to make this observation. However, so far I haven’t seen anyone point out that besides discouraging women from participating, equating abusiveness with leadership effectively ensures that women cannot attain positions of power.
Why? Well, if you believe that “jerks get things done”, it’s easy to go from that to believing that if you’re not a jerk, you must not be interested in “getting things done”; you must be someone who wastes precious time on social niceties. So if you believe that, you won’t recognize someone who is not at least occasionally rude and abrasive as a potential leader.
And, I argue, you won’t recognize a woman as a potential leader. Not because women can’t or don’t want to be rude — rather, because women are likely to already have been conditioned to be nice, and even if they haven’t, a hypothetical woman who led a major open-source project would never get away with being rude to people the way Linus is.
You might ask: how do you know? And in my opinion, all the evidence you need is contained in the comments on Sarah Sharp’s blog post. Sharp made a quite polite request; in return, she received numerous comments accusing her of rudeness, and of threatening what commenters say as a man’s right to be “frank and honest” (without stopping to consider the feelings of others). Some commenters seized upon the fact that Sharp’s post to the Linux kernel mailing list contained the word “fuck”, and scolded her for using a swear word while simultaneously defending Linus & company’s right to swear at people.
If you still need evidence that there’s a double standard, there it is. I think what’s happening here is that whatever men do gets defined as being effective, by definition, because they are men. It’s a little bit like how women frequently get describe as “emotional”, but this (often pejorative) label is rarely applied to men who are raging out, because apparently anger isn’t an emotion. (Thanks to Brenda Fine for originally pointing this out to me.) When a guy yells at his team members, he’s “being a leader”, “getting stuff done”, not wasting time with trivialities like being nice. But when a woman suggests that the whole team would be better off without the yelling, she’s “being oversensitive”, “reading too much into it”, wanting to stop everyone from ever saying “fuck” again. She can’t possibly be saying it because she has the best interests of the project in mind — because by definition, women are off-topic.
So that’s why the belief that “jerks get things done” is dangerous (and, in my opinion, false): it defines what leadership means so as to indirectly block women from being leaders. Because a nice polite woman can’t been seen as “a jerk, but she gets things done”; while a woman who swore and insulted people the way Linus does would be socially frozen out for violating gender norms. No matter what a woman’s communication style is, someone will focus on style and use that to ignore the substance of what she is saying.
What do you think?
- Are you a “frank and honest” woman? If so, do you think you’d be treated differently if others perceived you as male?
- Are you a guy who doesn’t want to be rude or confrontational, and if so, do you feel like you’ve paid a price for that?
- Are you a woman who’s tried to become more frank and honest, and had that backfire?
- Are you a guy who feels like you’ve gotten away with verbal abuse that a woman wouldn’t have been able to get away with?
- If you’re genderqueer, what set(s) of conduct standards do you feel people apply to you?
- If you’re trans, have you found that changing what gender others perceive you as made them more or less tolerant of your behavior (and did your behavior actually change?)
During Open Source Bridge last month, I went to a talk by Brandon Harris about the Wikipedia community. The focus of the talk was going to be on reasons why the number of people contributing to Wikipedia is declining. During the talk, I was reminded of why I don’t participate in Wikipedia anymore.
There’s a Geek Feminism Wiki page about what happened when I was nominated to be a Wikipedia admin in 2006. Until now, I haven’t mentioned in public that Catamorphism is me (though it’s easy enough to guess, since I still use that username on some other sites, and it’s also part of my primary email address).
In short, though, I’d been contributing frequently to Wikipedia a little less than a year at the time. Someone noticed my work and nominated me to be an administrator on the site. Admins have the power to use rollback (reverting an unhelpful edit with one click), as well as a few other rights and responsibilities. As is the usual process, a page — called an RfA (request for adminship) — was put up where people could either vote for, or against, me being an admin.
For a while, I was receiving almost all “Yes” votes. Then, somebody who apparently had an axe to grind made the claim, as part of their “No” vote, that I “made every discussion about [my] gender”. This person never substantiated their claim. As far as I can gather, it was based on the fact that during one talk page discussion, I asked somebody to use the pronouns I preferred at the time (they/them/their) when referring to me. After that point, I started receiving primarily “No” votes, and those people who gave reasons for their votes mainly said that they thought I would be a bad administrator because I would continue to make every discussion about my gender.
One of the primary values of Wikipedia is supposed to be substantiating every factual claim with a citation to a reliable source. None of the “no” voters asked for citations before deciding that the original claim — that I derailed every discussion to make it about my gender — was correct. They just believed the person who originally made the claim. I can only gather from this the “citation needed” label gets applied selectively on Wikipedia, and that unsourced claims that jibe with the existing beliefs of editors are less likely to be challenged.
Bizarrely, part of the RfA discussion devolved into various people debating what my “real” gender was. At the time I identified as genderqueer, but they were convinced that I must have some “true” gender that was different from that. Based solely on this picture of me, which I displayed on my Wikipedia user page at the time, some parties were vehemently convinced that I must “really” be male, while others were just as convinced that I must “really” be female. The picture was taken when I was 24 years old, before I started supplementing exogenous testosterone. I found it amusing that some people were absolutely convinced that they were looking at a man, when the only thing that made me a man at the time was invisible (and in fact, that’s still true, since the only thing that makes any of us the sexes we are is invisible — inside our heads). It illustrates the constructed nature of the sex binary. But I digress.
The RfA took an even weirder turn when the person who’d originally nominated me — a man using the handle of “Erik the Rude”, changed his vote from “yes” to “no” and announced he’d only nominated me to humiliate me, because he hated “bulldykes”. What follows was one of the only occasions when I’ve experienced serious harassment online because of my gender. A user of the hate site called Encyclopedia Dramatica (now rebranded as the warmer, friendlier site “Oh, Internet”) created an article about me that was solely based on the transphobic comments I received during my RfA. Because its title was my username — Catamorphism — and because Encyclopedia Dramatica had high page-rank at the time, the attack page was one of the first hits when someone searched for my username. “Catamorphism” is a technical term used in my field, so chances were good that potential colleagues or employers — just looking for information on a technical term used in the narrow professional field I work in — they would find a page with a picture of me and someone calling me a “bulldyke”. There’s nothing wrong with being a bulldyke, but it’s not a term that describes or ever has described me; if people are going to hate me, I’d prefer they hate me for who I am rather than what I’m not.
In the end, the “no” votes outweighed the “yes” votes — and again, I emphasize that the only real concern raised by the “no” voters was the unsubstantiated claim that I derailed unrelated discussions to talk about my gender — and I was denied adminship. I decided I didn’t particularly want to expend effort to contribute to a site that would have welcomed me as an admin if I was a binary-gendered person. I didn’t want to work with people who called it “disruption” to request that others use my preferred pronouns to refer to me, but didn’t consider it rude to misgender somebody. So I stopped editing.
Although I created a new account eventually and I still edit once in a while, I avoid editing that is potentially factually contentious. I just don’t have the energy to argue with aggressive people anymore. What’s more, I don’t have the energy to explain, over and over, that cissexual and heterosexual people’s points of view are not automatically more neutral and objective than the points of view of trans and queer people. I used to believe in the concept of “NPOV” (neutral point of view) that is one of the governing principles of Wikipedia, but I don’t anymore. The old saying is that history is written by the winners. Likewise, in practice, a neutral point of view seems to mean the particular point of view of whatever political groups have the biggest cognitive and emotional weapons. As a concrete example, I repeatedly ran into resistance and even ridicule when editing articles about trans people that used the phrasing “was born female” or “was born male”, to use the phrasing “was assigned female at birth” or “was assigned male at birth” instead. While the latter phrasing makes fewer assumptions, editors insisted that it was “POV” to say that people are assigned a sex at birth, but “neutral” to say that someone who may never have affirmed himself as female was born female. I can’t conceive of “NPOV” as being anything but a tool of domination anymore. Rather than striving for neutrality (which doesn’t exist), I would rather strive to mark opinions as opinions and provide citations for facts. I think it’s easier to distort the truth in an atmosphere of false neutrality than it is to do the same in an environment where it’s the norm to acknowledge your biases and the social position from which you speak.
Because of my experience, I found it hard to listen to the Q&A section of the talk, because what seemed missing to me was an acknowledgment of the fundamental brokenness that resulted in a group of cis people deciding to exclude me from volunteering in a certain role solely because I asserted myself as genderqueer. On the whole, though, I appreciated the non-technical talks I went to at Open Source Bridge because the presence of those talks made the conference feel like a place where nothing was off-topic.
When I first started reading Usenet newsgroups in 1995, one thing that was drilled into me by all the documentation I read was that you had to be on-topic. If you posted an off-topic post, you were wasting hundreds or thousands’ of people’s time, which was the worst thing you could do. Over time, I’ve come to enjoy online fora better when they’re community-based rather than topic-based. In 2006, though, being rejected as an admin felt like such a slap in the face largely because of the shame of being off-topic. Though it was baseless, I was being accused of bringing up something that wasn’t relevant, and of course, as someone who wasn’t unambiguously recognized as a white cis man, I wasn’t allowed to decide what was relevant; other people got that privilege.
I guess that’s why it was so gut-wrenching for me to be voted down. Later on, I experienced retaliation for reporting harassment that forced me to leave the graduate program I was in, and at the job I went to next, was threatened because I spoke out in favor of having a code of conduct that reflected awareness of power dynamics. Despite not putting my education or job in jeopardy, the Wikipedia incident was more painful for me than my experiences at either Portland State or Mozilla, because of the shame of being off-topic, and perhaps also because of the misunderstandings that lay at the heart of the RfA discussion. I was never heard in the Wikipedia discussion, and any attempts to make myself heard just elicited more refusal to listen.
I no longer seek out places where I’m required to stay on-topic, though, because I want to be my entire self wherever I am, as much as I can. Staying on-topic feels like having to leave part of myself at the door — whatever parts of myself the group I’m in doesn’t like very much. As Audre Lorde said, “There is no such thing as a single-issue struggle, because we do not live single-issue lives.” I appreciated Open Source Bridge because it felt like a broader acknowledgment that even programmers don’t live single-issue lives. At the conference, I went to talks on impostor syndrome, empathy, labor ethics, depression, and other topics that weren’t just about how to do thing X with software package Y. It made me feel like caring about the human side of computing didn’t make me a less qualified software professional, and like all of a sudden, it was the norm to have and acknowledge feelings rather than something that made me marginal. There were other little things about the conference that made me feel like I was the norm for once, too, like the all-vegetarian and mostly-vegan food at breakfast and lunch, and the “Intersectional Feminism Fuck Yeah!” stickers on the swag table. Going to the conference brought back a little bit of what my experience with Wikipedia erased: belief that there is a place for me in open-source culture and that what I have to contribute will be better because of — not worse because of — the ways in which I’ve experienced marginalization.
Crossposted to Tim’s blog on Dreamwidth.
The Empowermentors Collective is, in their own words, “a skillshare, activism, and discussion network for intersectionally marginalized people of color in the free culture and free software movement.” Also from their Web site: “We see radical potential in free culture and free software (often marketed as ‘open source software’) to work against ableism, racism, cissexism, heterosexism, sexism, and classism.”
I think this collective is a great idea, and while it’s not something that is open to me, I’ll do my best to spread the word about it. But one place I can’t spread the word is on any mailing list, forum, or syndicated blog post associated with my company. Since I work for an open-source company, Mozilla, that might employ people who are eligible for and interested in Empowermentors, that’s too bad.
Why is that? The Mozilla Community Participation Guidelines say: “Some Mozillians may identify with activities or organizations that do not support the same inclusion and diversity standards as Mozilla. When this is the case: (a) support for exclusionary practices must not be carried into Mozilla activities. (b) support for exclusionary practices in non-Mozilla activities should not be expressed in Mozilla spaces.” Empowermentors is exclusionary: it excludes white people, like myself. I support their right to create a safe space so that people who are oppressed can have one place that won’t be dominated by people in an oppressor class who may (even in a well-intentioned way) engage in derailing and silencing. So I can’t mention the group in a work mailing list email, or a post on Yammer (if I used Yammer), or in a post on my blog that is tagged so as to be syndicated to Planet Mozilla.
This illustrates a problem with codes of conduct that don’t explicitly acknowledge social power dynamics and call out the difference between a group that has a history of being oppressive doing things that reinforce the system of oppression in which it operates, and a historically oppressed group engaging in self-defense. Compare Mozilla’s Community Participation Guidelines with the code of conduct for the Open Source Bridge conference: “Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society.” With this one sentence, the organizers of Open Source Bridge communicated that the purpose of the entire code of conduct is to protect people who are abused, not to protect abusers.
Exclusionary groups that are for oppressed people are a positive force, because they give oppressed people time and space to talk about their oppression and/or just live their lives without explaining — or worse, justifying — their experiences all the time. For example, programming study groups that are for self-identified women only are a great thing, because it’s easier for women to learn when they don’t have to worry that if they say something silly or admit they don’t know something, the men in the room will hold it against their entire gender. As another example, when I was in college, I didn’t understand why the Black students’ organization had to exclude white students from participating. Now I understand that white people dominate almost every space, and having an organization where Black students at an overwhelmingly-white college can talk amongst themselves doesn’t hurt white students and helps Black students succeed.
But the Mozilla guidelines lump together these socially beneficial groups with white supremacist organizations or the Boy Scouts of America (which excludes queer men from serving as troop leaders). That’s a problem. As the Open Source Bridge code of conduct shows, it’s an easy problem to solve, as long as the priority of the people writing the code of conduct is to promote justice rather than to suppress tension.
Am I a hacker?
It’s a dense, challenging book with lots of food for thought, so I had too much to say about for just a comment on Yatima’s post. I’m going to write one post per chapter. This post is about the introduction to the book and chapter 1.
The beginning of the book left me with a slightly disoriented feeling. Eventually, I realized I wasn’t sure whether I was reading the book as an outsider to the subculture she’s writing about, or as an insider in it. Coleman makes the choice, which I agree with, to use the term “hacker” to refer to people doing open-source software. Am I a hacker? To decide, I figured I had to look no further than the Jargon File definition, which lists eight senses of the word:
1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users’ Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.
I’m already not sure how to answer. At one point, I would have absolutely said that I delighted in having an intimate understanding of the internal workings of a system. But with time, “delight” has come to seem like too strong a word. (If you’ve read my previous posts on Geek Feminism, that won’t come as a surprise to you.)
2. One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming.
“Enthusiastically” seems like a strong word to me now, too. But I certainly like programming more than I like theorizing about it.
3. A person capable of appreciating hack value.
Sure, I think I can appreciate it.
4. A person who is good at programming quickly.
Again, I’m not sure. I’m good at it, I think, but sometimes my anxiety gets in the way and slows me down to what seems like a snail’s place, and — aware of what’s happening — I get anxious about that too and get into a feedback loop. Plus, using a compiler with a long edit-compile-debug cycle, like I’ve been doing for the past two years, makes it hard for anyone to program quickly!
5. An expert at a particular program, or one who frequently does work using it or on it; as in ‘a Unix hacker’. (Definitions 1 through 5 are correlated, and people who fit them congregate.)
I’m an expert at a few particular programs, yes. (I’m not so sure I agree with ESR that these five definitions are correlated.)
6. An expert or enthusiast of any kind. One might be an astronomy hacker, for example.
This broad definition seems to include me, sure.
7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations.
8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence password hacker, network hacker. The correct term for this sense is cracker.
No. Though I’m no longer very sure that the correct term is “cracker” or that there’s really such an absence of correlation between definition 8 and the other definitions. ESR’s “[deprecated]” seems rather prescriptivist.
So I’m still not sure whether or not I’m a hacker. I’m still not sure whether my take on what Coleman wrote about hackers is the take of an insider — someone who can meet her neutral, anthropological gaze with the complementary perspective of inside experience. Or was my reading of the book the reading of someone who, just like Coleman, has never truly been an insider in hacker circles?
I don’t know. Sure, for the past two years my entire salary has come from writing open source software. But the words that stand out to me from the Jargon File definition, words that also feature in Coleman’s analysis of what makes hackers tick — “enthusiasm”, “delight” — don’t seem to be words that characterize my work days now. Though enthusiasm and delight are what got me onto the path that led me to where I am, they are also the things that make me feel distant from a lot of my colleagues, ones whose senses of enthusiasm and delight in their work seem less unscathed than mine.
Part of what I hoped for from Coding Freedom was a better understanding of what might separate me from them. I had high hopes for the book when I read the first epigraph:
“We must be free not because we claim freedom,
but because we practice it.” — William Faulkner
In this context, the quotation evoked what I’ve been trying to say in most of my Geek Feminism posts. That is: I’ve been trying to express my observation that when open-source people say they support freedom, they actually mean that they only support freedom for people who are like themselves and for people they see as their peers. Peers must be white, male, heterosexual, cis, and upper-middle-class — or, if they’re not all of the above, willing to use their freedom to say only things that white, male, heterosexual, cis, upper-middle-class people might say.
I finished reading the book feeling like either it didn’t get there, or it addressed this point in a way that was too subtle for me. Close to the beginning, Coleman mentioned that she wasn’t going to talk about gender politics. It’s understandable that she chose not to. Any woman writing about open source would run the risk of having her thoughts on gender dismissed because many male hackers believe women to be inherently biased about gender (and believe themselves to be, as men, not gendered and therefore not biased). The people she was writing about might well have extended that dismissiveness to her entire body of work. Of course, I don’t know if that’s why she chose not to address gender, but there are certainly many imaginable reasons not to.
And yet, without addressing the issue of who doesn’t get invited to the party of enthusiasm and delight that Coleman paints such an appealing picture of, there’s something missing. That said, I think gets it right in writing about the subjective experience of programming in a way that few writers that I know of ever have, which is remarkable for someone who hasn’t spent her life immersed in it — the only comparable writings about it that come to mind are Ellen Ullman’s books The Bug and Close to the Machine, and Ullman is both a programmer and a writer. Coding Freedom has bits that made me write “Yes!” in the margins all over the place, like on page 11:
…their deep engagement, sometimes born of frustration, and at other times born of pleasure, and sometimes, these two converge.
hacking is characterized by a confluence of constant occupational disappointments and personal/collective joys.
In encountering obstacles, adept craftspeople, such as hackers, must also build an abundant “tolerance for frustration”… a mode of coping that at various points will break down, leading, at best, to feelings of frustration, and at worst, to anguish and even despair and burnout
And yet, she goes on to say, the frustration isn’t all; hackers keep hacking because they’re pursuing (in Martha Nussbaum’s words) the unimpeded performance of the activities that constitute happiness. This rings true for me. When my work is going well, hacking is “the unimpeded performance of the activities that constitute happiness”, in a way that literally nothing else I’ve ever experienced is. And when it’s not going well, I keep going because I hope that that unimpeded performance will come again.
But then — in my opinion — she goes a little bit far: “In the aftermath of a particularly pleasurable moment of hacking, there is no autonomous liberal self to be found.” (p. 13) To which I say: if only! I know that I got into programming because it was a way to lose myself, to forget I had a self, to forget there was any such thing as “I”. It was something that, as a closeted trans teenager, I desperately needed — and that I got into programming (a route to middle-class financial success) instead of, say, crystal meth, was pure luck. But just like the pleasures of addictive chemicals (so I hear), the pleasure of programming diminishes with time, or at least it has for me. When it starts to be what you have to do — and surely most hackers aren’t trust fund kids, and have to earn a living somehow — it gets to be less fun. At least for me. Perhaps that’s a character flaw of mine; when people who have been hacking for decades say they still feel like the luckiest person ever to get to do it for a living, I’d like to believe they’re engaging in wishful thinking, but part of it worries that it’s true, while in the meantime, I’m incapable of ever feeling that way again.
Personal and Political
The personal pleasures of programming, though, aren’t divorced from politics, and Coleman acknowledges the connection vigorously. For example, on page 14:
Free software hackers undoubtedly affirm an expressive self rooted not in consumption but rather in production in a double sense: they produce software, and through this technical production, they also sustain informal social relations and even have built institutions.
I found this statement a bit unsatisfying. How can I produce without someone else consuming? (This is, by the way, why “maker” culture makes me uncomfortable. How much physical stuff does anyone need, regardless of whether they made it on a fancy machine or bought it at the Dollar Tree? Though at least with software production, the results don’t have to end up in a landfill if they aren’t needed…)
I like the idea of “unalienated, autonomous labor”, but I’m not sure how unalienated or autonomous most hackers really are — again, assuming that most of them have to work for wages and choose to do so by writing software (a plausible assumption since, it seems, software is rapidly becoming one of the few highly rewarding, low-risk career paths left in North America). I don’t feel unalienated or autonomous; I take orders, and I guess if I keep at this, someday I’ll give orders. I feel alienated because in order to earn a living as a programmer (which is the path of least resistance for me to earn a living), no matter where I work, ultimately my income is very likely to originate from one of a few sources: the military (killing bodies); advertising (killing minds, by creating desires for things that aren’t needed); or the finance industry (some of both). The pleasant emotional states I’m sometimes able to achieve while writing code don’t change that fundamental reality.
Around this point in the book, I started wondering how much of Coleman’s analysis is predicated on the assumption that hackers work for free. My experience is that most don’t. The vision of a programmer coming home from work and immediately retreating to the basement to work on an open-source project for the pure joy of it, unrelated to work (no doubt while his wife cooks dinner and scrubs the bathtub) is a romantic one, but I’m not sure how common it actually is. Lots of open-source work gets done on the clock, simply because corporations recognize that sometimes, sharing the code results in more profit. (Coleman does acknowledge the latter fact later on, but the story she tells is of the original, free, pure, Stallmanesque vision getting corrupted… and I’m not sure there was ever anything to corrupt in the first place.)
When Coleman says hackers support “a liberal politics of free speech” (p. 15), I was hoping for more analysis of just whose free speech hackers support, but I didn’t find one. In fact, in my experience, the kind of free speech hackers support is quite narrow. Racist, sexist, homophobic, transphobic, and ableist speech must be protected; any criticism of such speech must be suppressed in order to protect the free speech of those who would make remarks that marginalize and exclude (I guess you have to kill free speech in order to save it). Later on the same page, she writes “From an ethnographic vantage point, it is important to recognize many hackers are citizens of liberal democracies, and have drawn on the types of accessible liberal tropes–notably free speech–as a means to conceptualize their technical practice and secure novel political claims” — which I thought was closer to the truth. Consistently with the selective nature of the application of the “free speech” trope, hackers don’t believe in free speech for its own sake; they use it because it’s a powerful tool for getting support. At least in the kinds of liberal democracies Coleman is talking about, no one wants to say they’re against free speech.
When outside is inside
By the way, so far I’ve just been talking about the introduction to the book. Chapter 1 begins by describing what the early life of a hacker might be like. When I read it, I was hit by a wave of jealously, to be honest. My early life was very little like the prototypical genesis of a hacker that Coleman describes. ‘A hacker may say he (and I use “he,” because most hackers are male)…’ — well, I am male, but nobody recognized me as such until I was in my late twenties. I didn’t take apart electrical appliances, because I would have been afraid of the consequences my abusive mother would have imposed if I’d experimented in such a way. I didn’t teach myself to program when I was six or seven, because we couldn’t afford a computer and I’m not sure my mother would have thought to buy me one even if the money had been there. I was just barely too young to get in on the BBS era, even though I finally did acquire a computer and modem in my mid-teens. When I did get access to a computer, I wasn’t too interested in UFOs, conspiracy theories, or warez — actually, what I was interested in was connecting with other people who were like me. That, oddly enough, was what led me to hacker culture and then to programming. (And there was some porn mixed in there, I’ll admit.) The only part that does sound familiar is “The parents, confusing locked doors and nocturnal living with preteen angst and isolation, wondered whether they should send their son to a psychologist.”
So maybe I’m not a hacker. Maybe I’m just a professional programmer who lacks that extra je ne sais quoi that would make me not just a workaday programmer, but a hacker. (If you read the Jargon File, you’ll notice this boundary being drawn repeatedly — between hackers, who program for fun, and do so even when not getting paid; and staid, dull, programmers, who might wear ties and write Cobol. That sounds like a class stratification and one that hackers might well be using to their advantage.)
Next to the line (on page 26) “Nonetheless, he grew to adore the never- ending, never-finished nature of technological production, and eventually fell, almost entirely by accident, into a technical movement.”, I wrote the note, “what about the part where you start hating computers?” And I’m reminded of a tweet that my friend Caylee Hogg wrote:
“I’m not in cs because I like computers. It’s that I don’t trust them and want to keep an eye on those fuckers.”
And I really think this is a key distinction. The hackers that Coleman talks about seem to be genuinely working with computers because they like them… but for Caylee, and me, and not a few others, it’s about not trusting them — and for me, at least, not trusting the people who like them. I work on statically typed programming languages with type systems designed for soundness because I don’t trust the intentions of hackers, cowboy coders, or anybody else who’s immersed in enthusiasm for programming — because enthusiasm for programming doesn’t tend to go along with rigorous attention to quality, to handling corner cases well, or to designing user interfaces that non-programmers can use without frustration (just to name a few things); it doesn’t go along with empathy for people who aren’t programmers.
I’m getting off the topic, but I guess it’s to do with more of why I’m not a hacker, why my reading of Coleman’s book is as an outsider, albeit one who has spent time among hackers, just as she has.
Of love and snark
In about this part of the book, I began to wonder whether hackers really, uniformly, love everything about computers and software. Am I not a hacker because I don’t? Or is the love less black-and-white than the picture Coleman paints? (The use of “sensuality”, on p. 27, might be a stretch.)
The life she’s describing in this chapter seems to be the life of a quite privileged child, one with genial parents who (at the least) provide a computer and a room of one’s own. Or perhaps it’s the privilege, as well, of having grown up in a particular era: “time, most programmers who learned about
free software anywhere between 1985 and 1996 greeted it as if they had stumbled onto a hidden treasure trove of jewels, with the gems being Unix-based
software and its precious underlying source code.” I was born just a bit too late, I guess, because by the time I installed Linux for the first time (1999), I just sort of took it for granted that there was a free Unix.
Likewise, the excerpt from the Jargon File about “larval stage”…
“the ordeal seems
to be necessary to produce really wizardly (as opposed to merely competent)
…makes me think I’m not a really wizardly programmer. Maybe all of this is the lament of the non-wizard, and I don’t have a clue about what it’s like to live the experiences Coleman documents because I’m not a wizard.
Reading the Neal Stephenson quotation on p. 37, though, I recalled that not all hackers are united in love for Unix — for example, how about the Unix-Haters’ Handbook? I think it does hackers a disservice to suggest they’re so united about any ideological or technical question. Coleman talks a lot about hacker humor, but I think she still doesn’t give the full picture… the one she gives is more of the hero-worshipful side of hacker culture, the one that turns me off, and less of the snarky, iconoclastic side that’s expressed in the Unix-Haters’ Handbook. It’s the difference between the “worse is better” philosophy and the “worse is still bad” philosophy. The latter one is the one that hopes to do better — and, I’d hope, it’s related to the one that hopes to do better at including everybody.
Coleman brings up an interesting point on p. 38: that initially, hackers saw free software as equivalent to ‘free beer.'” This is especially
ironic, since some programmers now adamantly insist that the free in free
software is precisely about “speech, not beer”. Ah, backjustification. When I was nine, I wanted to become a vegetarian because I didn’t like meat. Not too long after, I read that some people were vegetarians because they didn’t like killing animals. I decided that I, too, was one of these “ethical vegetarians”. But to be honest, I never liked eating meat in the first place. Perhaps the slogan “free as in freedom, not as in beer” is a little bit like that. And anyway, how different are these concepts, really? Beer is one thing, but if finding food is what you spend most of your time on, you’re not going to have a lot of time to exercise your freedom to hack, even if it’s technically there. The same logical fallacy seems to underlie the popular Silicon Valley slogan of “I’m fiscally conservative and socially liberal.”
Page 41 is Coleman’s first use of “meritocratic” that I noted, but it probably shows up before. One thing that continues to bother me about the book is that she uses this word seemingly uncritically. As we’ve covered before, the word “meritocracy” is inevitably a smokescreen for covering up the unfair advantages that abled white heterosexual cis men receive. Perhaps Coleman was silently putting air quotes around the word, but I don’t see them.
There are actually at least two ways to think of meritocracy: one is the sense Coleman uses, where the insiders form a set of standards that the outsiders must meet in order to become insiders (possibly higher standards than the insiders themselves ever had to meet). But another sense of meritocracy is one where it isn’t the insiders, with their superior power, who get to define the standards for inclusion. Another way to think about meritocracy is to treat it as a priority to bring as many people into the community, so they can contribute, as possible. That’s a formulation that has a lot more to do with acccessibility, as I’ll talk about in a bit.
Again, when on Page 47 in a lengthy discussion of hacker conferences, she says, “These types of intense, pleasurable emotional experiences and expressions are abundant”, I want to emphasize that such experiences are largely limited to hetero, cis, white, abled men. The more intersecting identities someone has, the more restricted their access to these experiences and expressions is. It’s unfair not to mention that. It’s hard to let go and have a blissful experience geeking out with peers at a conference if they don’t see you as their peer and they express that by trying to grab your crotch at the first opportunity. Likewise, it needs to be specified who is welcome at the “rituals of confirmation, liberation, celebration, and especially reenchantment” (p. 48)
Speaking of “enchantment”, this part of the book reminded me of the hacker trope that involves using words like “wizard” and “priest” to refer to people who know a lot about computers. Since these words are usually coded as male (calling someone a “witch” to mean she was a good coder would come across very differently), they serve to reinforce the belief that only men can be good at hacking. A belief in the value of logic and rationality goes along with hacker culture, yet there’s nothing very logical or rational about attributing magical powers to people who are simply very good at a skill they’ve practiced a lot.
Open Source Values
In Chapter 1, Coleman talks a lot about the ways in which hackers value freedom and meritocracy. These are not the only possible values that could be the driving forces behind hackers’ communities of practice. Even though many hackers identify as outsiders and as idealists, their values look a lot like the standard narrative behind Western neoliberalism. Why is that? Coleman touches on it somewhat in later chapters, but one thing I felt was missing was a discussion of other value systems that could drive open-source development, though right now they don’t.
One of them is accessibility (in these thoughts, I’m influenced by Choose Your Own Logic). In computing circles, where it’s referred to as a11y, “accessibility” often refers to making computer software and hardware easier for people with disabilities (often disabilities related to vision) to use. That’s important in itself, but I think accessibility could be construed a lot more broadly. The hacker approach that Coleman talks about is about making it possible for anyone to use software… so long, that is, as they have the cognitive and emotional resources to put up with lots of frustration and arbitrariness, to learn lots of seemingly arbitrary rules, and deal with broken systems (often by fixing them). Do you have to meet this high bar in order to be able to contribute to software? Or just to be able to get something out of it? If not, maybe accessibility as a value might be worth considering. Another thing that acccessibility that means to me involves documentation. As tangentline on Twitter pointed out, if software isn’t well-documented and you have to go on a potentially hostile IRC channel and negotiate a likely-male-dominated hacker space in order to get information, that’s putting up a barrier both to its use and to people who might otherwise be able to contribute to it. So to me, another part of what accessibility means is to prioritize good documentation so that it’s easy for somebody to get involved without immediately having to navigate an unsafe social situation. And I suspect that hackers’ famed antipathy to documentation writing is not an accident — if people have to navigate informal social rules rather than having formal documentation to consult in order to get involved, it shuts out people who aren’t a good “culture fit”.
Another value is quality. While I want to be clear that I’m only speaking anecdotally here, as someone who’s worked both in academic research groups that were about applying formal methods to prove stuff rigorously about software, and in software companies, there seems to be a lot of tension in both directions. In hacker circles, programming quickly seems to be more valued than programming correctly. If you read through the Jargon File and other hacker writings, there’s a lot in there about the joy of a good hack and the importance of releasing code early, and not as much about the pleasure of stating formally, in a machine-checkable language, what your code is actually supposed to do (not surprising, since that’s really just another form of documentation). Quality matters not for some obscure, pointy-headed, theoretical ivory-tower sense of purity — but rather, because when software has bugs, real people waste their time (and potentially, money and lives). Valuing writing software quickly, but not valuing writing software that’s correct and reliable, reflects a sense that other people ought to be doing the work that’s not so interesting.
I think accessibility and quality are related. I think that having the patience to learn how to cope with and use bad user interfaces reflects a lot of privilege. It’s not as if there’s no one in the hacker community who’s urging more attention to user interface design and pointing out that even experts need software that works: for example, git, despite being a widely popular version control system at this writing, has many critics, particularly with respect to its user interface. The hacker classic The Unix-Haters’ Handbook (I’m thrilled to discover that the full text of it is online now as a PDF) spends a lot of time criticizing the elitist attitudes that the authors perceive behind Unix advocacy — specifically, the assumption that if you as a user find a system difficult, it’s your fault for not being smart enough, rather than the designer’s fault for not making it accessible. It’s somewhat notorious that when somebody submits a bug report to an open-source project, they’re likely to be told that the software works fine and it’s their fault for using it wrong; there’s a story I can’t find just now about a Ubuntu utility that deleted your entire filesystem when used incorrectly, and in a bug report, its creator staunchly defended this functionality, saying the tool was for experts and it wasn’t his fault if a non-expert happened to try it. I think such an attitude is totally compatible with valuing freedom above all, but I don’t think it’s compatible with balancing freedom and accessibility.
All I really want to say here is that when we talk about how the open source community values freedom, it’s easy to get lost in lofty rhetoric; easy to forget that freedom is just one value, that must be balanced with others. One area where I think Coding Freedom falls short with its extensive discussions about how open-source people talk about free speech and critique intellectual property law is examiningwhat they’re not talking about and not critiquing.
Being outside looking in at outsiders
Lest you think I’m being too negative, I wish I could go to a con like the ones she’s describing: “Reflexivity and reflection are put on momentary hold, in favor of visceral experience.” But such experiences may not be available to me, even though I’m fairly privileged. Though I’m usually assumed to be a hetero, cis, white, abled man (though I’m not hetero or cis), somehow I still feel shut out of the cool kids’ club among the kids who got there because they weren’t welcome in the cool kids’ club. Maybe it’s because I have a defiant consciousness, because I remember how different it was to move in hackish circles when people saw me as a woman. Or because I listen to my friends now who are women hackers. Maybe the loss of innocence that came with all of these things just makes it impossible for me to have that “visceral experience” without the critical part of me engaging and noticing who’s excluded.
I don’t want to come off as totally critical; in pages 59-60, Coleman does acknowledge, “The poor, the unemployed (or the overly employed who cannot get time off to attend these events), the young, the chronically ill, and those with disabilities often cannot attend.” But that’s just the beginning. I think her beautiful, deep analysis would be even more beautiful and deep if it centered the outsiders, the fringes of the hacker community rather than her chosen focus, the people in the center.
A few months ago, I attended a talk at Mozilla by Ted Nyman (of Github) titled “Scaling Happiness”. The video is freely available.
Nyman argued that companies with minimal formal structure are better for workers (specifically, better at maximizing workers’ happiness) than more traditional companies. Whenever someone asks whether something is “better”, I ask “better for whom?” Whose happiness was Nyman talking about? He didn’t say, but when I think about happiness, I ask what’s best for women, for people in GRSMs (gender, romantic and sexual minorities), for disabled people, and for people of color, since not too many people seem to think about what’s best for people in these groups. (For the record, I’m in the second and third of those groups, though I’m usually not perceived that way in one case, and often not perceived that way in the other.) Happiness for the dominant cadre in the software industry — that of people who have white privilege, male privilege, cis privilege, and heterosexual privilege, and who lack visible disabilities — is not the same as happiness for everybody.
I don’t mean to say that happiness is a zero-sum game, that when abled white cis men are happy, that inherently takes away some of the limited pool of happiness from disabled trans women of color. Rather, part of the problem is that people who have privilege perceive happiness as a zero-sum game; part of their happiness comes from seeing themselves as better than others.
I think most people in the tech industry or in open-source or free culture communities know what I’m talking about when I say “structurelessness”. Perhaps you work at a “flat” company that encourages employees to make up wacky job titles to put on their business cards, calls everybody a “team member”, or renders everyone uncertain about who their boss is. Or maybe you’ve only worked at more structured, hierarchal organizations: ones with managers, a complicated organizational chart, ranks, and hierarchy. You probably know the distinction even if you’ve only been on one side of it.
Does structurelessness eliminate competition, abuses of power, and status hierarchies, or does it just drive them underground? To break down the question, let’s look at a few ideas about structurelessness, some of which are from Nyman’s talk and others are just things I keep hearing from people in the free/open-source software and culture world.
- Authenticity: people are happier when they are able to be who they really are at work.
- Informality: people are happier when they’re able to be informal at work, such as by wearing T-shirts with holes in them or saying “fuck” a lot.
- Conduct: formal mechanisms for guiding behavior aren’t that important, since in a healthy organization, people will just be nice to each other.
- Leadership: people whose job it is to manage aren’t necessary when people can just manage each other.
- Accountability: formal goals and performance metrics just get in the way of getting a job done.
As a nod to structurelessness, I’ll take on these points in no particular order.
First, why would a feminist argue in favor of structure when structure so often means hierarchy, and hierarchy is deeply entwined with oppression?
It’s true, I’m not a big fan of hierarchies. Maybe they can be used for good, but I haven’t seen a lot of that in reality. At the same time, though, it’s also a fallacy to think that simply declaring we’re not going to have hierarchies makes hierarchy go away. Jo Freeman wrote about this in the ’70s, in her essay “The Tyranny of Structurelessness”. Based on her experiences in feminist organizing, she found that groups of people (like feminist consciousness-raising groups) that declared they weren’t going to have a formal structure devolved into unofficial hierarchies, which were much harder to challenge and hold accountable.
Do you trust people to see you for who you are? I mean the question in two senses: (1) Do you believe that it’s even possible for you to communicate who you are to others without a great deal of effort, and (2) Do you trust others, as a general rule, enough to assume they will behave cordially towards you once they know who you are?
In his talk, Nyman talked about how in typical companies, many relationships are inauthentic. That is, people don’t act towards each other in the ways that they would in the absence of a rigid, externally imposed set of relationships. At least stereotypically, people don’t behave towards their bosses, or to their subordinates at work, the way they behave with their friends. He argued that people are happier when they can present themselves authentically and have authentic relationships, and that a less structured organization fosters such relationships.
If you are queer, or trans, or have mental illness, or all of the above, you probably know something about the perils of presenting yourself as you really are. Dan-Savage-style coming-out narratives notwithstanding, many of us who are placed socially in these ways find that we cannot be completely authentic in all aspects of our lives. I definitely want to express myself, but I have to balance that against other needs, like being able to make a living in a capitalist society. If I dressed the way I’d prefer to, if I talked more openly about the times when my depression and anxiety prevent me from getting work done, I might find it harder to fit in, to stay attached to a professional group, to stay employed, than I already do. So instead, I wear T-shirts and cargo pants, and I let people think (at times) that I’m merely disorganized or not that committed to what I do.
In my opinion, it takes a lot of privilege to assume either that greater authenticity leads to greater happiness, or that the only reason you would leave who you are at the door when you step or roll into work is the formal, organizational structure of the place where you work.
Moreover, being your authentic self in front of somebody else requires trust, and outsiders have very good reasons not to trust insiders. For me, part of what I mean when I say I lack a certain amount of privilege is that every day at work, I make calculations about who is safe to interact with and who is unsafe. Of course, there are degrees of safety and it’s not a binary choice. For example, every time someone uses “crazy” as a pejorative — suggesting that what I am is also a label to insult an idea with — that decrements their “safety” score inside my head. Almost everyone uses this word in this way — even I still do, given that I’m not free of internalized ableism — which is why I say it’s not a binary property. If my company became totally flat and got rid of all structures, processes, and goals, I wouldn’t be able to have authentic interactions just because of that. I’d still have this calculus of safety I have to apply all the time.
And what about when who you are makes people uncomfortable? If you’re queer, trans, kinky, poly, disabled, you probably either have spent a lot of time trying to blend in, or you have stories about when people become uncomfortable upon realizing some aspect of who you really are, and having to comfort them. (Or both!)
To take a completely different example, do you really want to encourage people to be “who they really are” when who they really are is a harassing creep? Maybe having to be a bit inauthentic at work serves an equalizing function, like a uniform. If you know what the rules are, it’s more likely that you’ll be able to follow them and less likely that you’ll be cast out for breaking a rule you didn’t know existed.
Informality and isolation
Usually, no one tells little kids on the playground who to play with and who not to play with. But even very little kids start forming hierarchies of exclusion when left to their own devices. Vivian Paley’s work, as documented in her book “You Can’t Say ‘You Can’t Play'” showed both that in groups of kindergarteners, leaders emerged who got to decide which kids got to play and which kids got excluded; and that a teacher could change that by imposing the simple rule that “you can’t say ‘you can’t play'”. And increasing the amount of inclusion in the group made the kids in it feel more accepted, on the whole. An advocate of structureless organizations might argue that Ms. Paley should have just let her pupils be their authentic selves and form their own social alliances. But at least according to Paley’s account, imposing the rules made the kids happier — contrary to Nyman’s claims about structurelessness and happiness.
Now, perhaps kids are just different from adults. I also don’t think it’s necessarily human nature to form hierarchies in the absence of formal rules. Fundamentally, I don’t care whether that’s because of nature or nurture. No matter what combination of nature or nurture it is, as human beings we have the latitude to choose what we will value. Personally, I value inclusion, and while I can’t prove logically to somebody else that this is something they should value too, I think there’s plenty of evidence that inclusion and the overall happiness of people in a group correlate. And, as Paley’s kindergarteners show, inclusion does not necessarily naturally arise from structurelessness.
Isolation is closely related to an insidious way in which people who believe themselves to be good can perpetuate oppression: the withholding of mentorship. In another context, that of law schools, Pamela J. Smith wrote about how even when Black women gain admission as law students, informal social barriers to the development of mentoring relationships with faculty members are a form of discrimination that is difficult to challenge (“Failing to Mentor Sapphire: The Actionability of Blocking Black Women from Initiating Mentoring Relationships”, reprinted in Critical Race Feminism, Adrien Katherine Wing ed.)
Informal mentoring between apparent peers is mediated by social power dynamics as well. In her book Leaving The Ivory Tower, Barbara Lovitts wrote about the importance of tacit knowledge in determining whether Ph.D students succeed or fail. Many graduate programs are quite structureless in a day-to-day way; despite having a clear hierarchy (tenured faculty, tenure-track faculty, non-tenured instructors, postdocs, grad students), new graduate students must navigate a system with very little formal structure in order to learn the unwritten rules of the game. The difference between being a popular person and an unpopular one in grad student social groups can be the difference between academic success and failure. Would fewer grad students drop out because of isolation if there was a more formal process for initiating beginning students?
In my personal experience as someone who, earlier in my life, didn’t resemble most of my colleagues, lack of mentorship is a major structural barrier to success both as an academic computer scientist and as a software engineer. And I think lack of structure translates into lack of mechanisms to encourage formal mentoring relationships — something that has a disparate impact on women, people in gender, romantic, and sexual minorities, people of color, disabled people, and everybody else who may not feel comfortable approaching someone of higher social status to ask for support.
Likewise, people with disabilities that affect how they process tacit social cues — such as people who are on the autism spectrum — may have a much easier time contributing harmoniously when the rules are made clear than when they must access all resources by guessing at a system of unwritten rules. Since ability to write software isn’t contingent on being neurotypical, barriers to entry for neurodiverse people mean excluding a portion of the talent pool for no particular reason.
When a marginalized person joins an organization, in the absence of structure, isolation and lack of mentorship can combine to render them powerless and unable to ask for — or perhaps even express — what it is that they need. In such a situation, it’s easy for that person to then be labeled “unproductive” by the very community that has, without even knowing it, made it impossible for that person to learn and grow. Formal structures are one way to level the playing field and make sure that everyone has the same opportunities, regardless of whether senior folks in the organization find them initially easy to relate to or identity with.
Codes of conduct and diversity expectations
I don’t know how a structureless organization would maintain or enforce a code of conduct. Maybe in such an organization, everyone just likes each other so much that it’s not necessary to have one. But codes of conduct aren’t needed because people aren’t nice or because they don’t like each other; they’re needed because different people have different expectations about what kind of behavior is appropriate in which contexts. It doesn’t seem to me like getting rid of formal structure solves that problem.
Codes of conduct are just one way to help a group become or remain diverse, by ensuring a safe environment for everyone and providing mechanisms to address breaches of that safety. Without formal structures, how does a company make and keep itself diverse? While the practice of affirmative action is often inaccurately derided as “quotas”, a few tech companies do go as far as to institute numerical quotas for hiring women. I would suspect that such a practice, and even more flexible affirmative action concepts, would conflict with informality. But how does a structureless organization avoid devolving simply into hiring friends?
In general, how do you make sure that an organization without structure doesn’t default to recreating the same power hierarchies that exist in its underlying society? I asked this question during the question and answer period at Nyman’s talk, but it got a little lost in translation. Nyman’s answer amounted to “we won’t hire racist or sexist people”. But that’s not good enough. Everyone raised in a white supremacist society has unconscious racism, and everyone raised in a patriarchy has unconscious sexism. It’s obviously inadequate to dismiss the possibility of recreating systematic oppression “because most of us are good ethical people”. Nyman himself admitted that Github is getting less diverse.
Unless it literally consists of a collection of people, each working alone — in which case you’d wonder what makes it an organization — in an organization without people formally titled “manager”, people will have to step up to manage each other at least sometimes and to some extent. How do you take initiative and assert power — in the absence of a structure that makes that power legitimate — when you’re already culturally oppressed and disempowered? If nobody is a manager, who will be most successful in, say, asking that their team institute a “run regression tests before committing code” policy: a tall, white, able-bodied, cis man; a short, Latina, disabled, cis woman; or a fat, Black, genderqueer person? When is it possible for people to really treat each other as equals, and when do they infer hierarchies when not given a formal hierarchy to look to?
What about when you’ve been punished in the past for trying to regulate others’ behavior instead of “knowing your place”? If you’re perceived as female, knowing that girls who assert power get called “bossy” and women who assert power get called worse, but also knowing that your leadership skills will eventually be called into question if you don’t assert power, structurelessness starts looking like a double bind.
Without goals and performance metrics, how do people get held accountable? I don’t just mean accountability for delivering on the promises one makes as part of doing one’s job. How about, for example, not finding a subtle way to fire somebody for discriminatory reasons and make it look like it was performance-related?
In his talk, Nyman acknowledged that more “formal” processes are necessary for handling harassment: he acknowledged, “you can’t just go to anyone” if you’ve been harassed. But what else, falling short of “harassment” as such, might require a formal process?
I’ve been pretty negative about structureless organizations. But there might be positives. Are they more open than more traditional companies to people with less formal education, or whose biographies are otherwise non-traditional? (I don’t know.) Do they make it harder for entrenched managers to retain power by virtue of seniority? (Again, I don’t know.)
To be fair, there isn’t just one set of processes that could arise when an organization sets aside formal structure. The majority could end up ruling most of the time. Or an organization could make decisions based on consensus. Or it could be cloyingly called a “do-ocracy”, in which decisions get made by whoever has enough time and energy to implement the consequences of the decision. I still think there’s the risk of majority rule, though, and the problem with that is that decisions about basic rights, respect and dignity can’t and shouldn’t be made by a majority. Where do basic rights, respect, and dignity come into this discussion? The number of occupations that are at least potentially a route into the middle class, at least theoretically available to anyone who has acquired a certain skill set that is possible for anyone dedicated to acquire, is steadily decreasing. If you’re in a social class such that you need money to live, learning how to program isn’t a bad way to go. But that will only continue to be true if tech company jobs are open to any qualified candidate, without the hidden price tag of humiliation based on one’s race, gender, disabilities, or sexual orientation.
Majority rule is, then, a problem because majorities often opt to keep minorities in their place for the benefit of the majority. And yes, a group made up of entirely people who see themselves as good and ethical can and will deny basic rights, respect and dignity to people based on gender, sexuality, ability, race, class, and other axes of oppression. The world might be different someday, but we can’t get there by pretending we are there.
Your thoughts, readers?
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
— The GNU General Public License (GPL), Version 3
At the beginning of this year, First Monday (a longstanding, online-only academic journal) published Joseph Reagle’s article “‘Free as in sexist?’ Free culture and the gender gap”. The article is the only comprehensive study I’ve seen so far of online discourse drawn from free and open-source software and data communities that focuses on attitudes towards gender and sexism.
In what follows, I examine Reagle’s presentation of two major themes: how dominant definitions of “geek identity” serve to keep communities homogeneous; and how ideologies held by open-source workers sometimes serve to justify mistreating people in the name of freedom of speech. Finally, I suggest another reason for open-source communities’ problems with diversity and equality: an economic one. I’ll use the terms “geek culture”, “open source culture”, and “hacker culture” roughly interchangeably. Not all geeks or hackers work on open-source projects, but open-source communities represent, to me, a highly valued position in the hierarchy of value subscribed to by many people who identify as geeks and/or hackers.
I had a visceral reaction to the “On being a geek” section of “Free as in sexist?” This section covers ground that is familiar to me: the obsessive, monomaniacal approach to programming that hacker culture valorizes; the relationship between this style of working and a confrontational, aggressive style of argumentation; and the relationship between geek identity and normative whiteness and maleness. (As I don’t have any special authority to speak about race or racism, I won’t discuss those issues in depth here; I recommend Mary Bucholtz’s paper “The Whiteness of Nerds: Superstandard English and Racial Markedness” [PDF link], in which she argues that American nerd culture consitutes an explicit rejection by certain white youths of those aspects of American popular culture that arise from Black Americans.) Even so, the section affected me on more than just an intellectual level. As I read the quotations Reagle chose from sources such as Richard Stallman’s and Joseph Weizenbaum’s writings, as well as interviews with women studying computer science, I felt afraid and disappointed. I felt ready to get out of this field myself as fast as possible. Before I could help myself, my subconscious was already rushing ahead and reviewing the plans I’ve turned over in my head about jobs and careers that I could do that wouldn’t require me to be either a Toxic Open Source Guy, or an enabler for one.
When I was 15, sleeping in a lab and working for 20 or 30 hours at a stretch appealed to me. I wanted to lose myself in code, stop noticing my physical body because I was too engrossed in turning over abstractions in my mind. I think some part of me thought that if I got to be a competent programmer, it wouldn’t matter that I didn’t know how to form connections with other people or that my body was the wrong shape for me. I know now that escaping into work is not a helpful coping mechanism for me. Nowadays, I’ve exercised agency to make my body more comfortable for me; I see a therapist; and I have friends. I want to do my job reasonably well for eight hours a day and go home. I don’t want to run away from life outside the screen by immersing myself in work. I know most of the guys who do the sleep-in-the-lab, work-twenty-hours thing aren’t running away from what I was running away from. (I wonder what they are running away from.)
In Reagle’s article, I read, “Bente Rasmussen and Tove Hâpnes found female CS students who did not want be associated with the dominate [sic] identity of “key-pressers”, i.e., those who were not able to talk about anything beyond computers.” I thought — that’s me, too! I don’t want that either. I don’t think I have to quit being an open-source programmer if I want to have an identity that isn’t just about computers. But sometimes when I’m around people who do seem more like key-pressers than I am, I feel like that’s the way I have to be in order to fit in and be accepted.
Then I try to imagine what it would be like for me if on top of all of this, I felt like I had to conform to a vaguely woman-ish gender role. I didn’t know I wasn’t female until I was 18, and didn’t know I was male until I was 26, but I never felt much pressure to be what girls or women were supposed to be. On the other hand, if I was a cis woman, or even more so, if I was a trans woman (since trans women get expected to conform to gender stereotypes for women even more so than cis women are when their trans status is known), working in the industry I work in, I would have an almost impossible set of constraints to solve. As Reagle shows, success and status in open-source (and even in non-technical “free culture” communities like Wikipedia editing) are correlated with adopting a (superficially) overconfident, aggressive, argumentative persona. Women get to choose between being socially stigmatized for violating gender norms, or being ignored or mocked for violating open-source cultural norms. It’s a double bind.
Reagle quotes a passage from Margolis and Fisher’s Unlocking the Clubhouse: “‘Scary’ and ‘afraid’ are words that recur again and again.” For me, these are emotions that recur again and again when dealing with open-source culture, and when recalling the memories that reading Reagle’s article brought to mind. What strikes me, though, is that I’m almost twice the age of some of the undergrad students who Margolis and Fisher describe. When I was those students’ age, CS culture seemed safe, not scary. It was the rest of the world that was scary to me. Now, something’s changed. I think part of it is that I’ve had too many conversations with colleagues about gender politics that leave me feeling angry, frustrated, and helpless. Those interactions leave me afraid of being dismissed, dehumanized, objectified, or belittled again if I speak up. I’m also afraid of the sinking feeling that, for me, comes from being silent when I witness something I know is wrong. After a while, just walking in the door to the office seems like an entire day’s work.
Another quotation (from a social psychology journal article by Sapna Cheryan and colleagues) that stood out to me was “The profoundness of this alienation is hinted at in a recent study that found even an ‘ambient environment’ of stereotypical geeky items in a room (e.g., science fiction memorabilia and junk food) depressed female undergraduate interest in computer science.” While looking for a new place to live near my workplace in Mountain View, Ca. recently, I was browsing through rentals on AirBnB, and found a post advertising a bunk in a “hacker fortress”. I think the feeling I had when imagining living in such a place might be akin to how the women in that study felt when they saw a roomful of Star Trek figurines and Mountain Dew Code Red bottles. At 15, the summer I was doing an unpaid programming internship and drinking Jolt in the mornings, living in a “hacker fortress” would have seemed like an exciting idea (never mind the potential rape and sexual harassment that someone who looked like I did at 15 would have experienced — I probably would have dismissed that risk at the time). Now, even contemplating having to live in a place with a name like that sends my stomach dropping through the floor.
This section of Reagle’s article is valuable for showing that what I and so many others have experienced is part of a pattern; it’s not a coincidence, nor is it due to some weakness of character that we all happen to share. Women who have been involved, or tried to be involved, in free culture encounter hostility, not as a universal rule but as a recurrent pattern. It’s certainly not that Joseph Reagle is the first person to point out that free culture is systematically hostile to women — women have been saying this for a long time. But the evidence he collects is one more persuasive tool to put in the toolbox for convincing the naïve that yes, geek culture has a sexism problem. In the long term, though, we won’t have made any progress if people in the dominant group only believe women’s experiences when a male academic documents them.
It’s not just women who have been saying it, either. What Reagle doesn’t mention is that queer, trans, and genderqueer people in open-source share many of the same experiences that women do. In my opinion, like most transphobia and homophobia, that’s collateral damage from a fundamental hatred of anyone perceived as departing from a constructed heterosexual, cis male ideal — and that includes cis and trans women, as well as queer men and genderqueer and gender-creative people. (The omission of queer and gender-non-conforming people’s experiences could be due to a lack of written sources documenting it; there are various reasons why people in gender, sexual and romantic minorities might talk about their stories in a forum that lacks a permanent record.)
What makes me sad about all of this is that I still want to be around intellectually curious and playful people who are passionate about learning and making things (though, ideally, ones who don’t limit their inquiry to a single narrow specialty). I still want to have peers who inspire me to be and do more. I still love nerd humor when it isn’t mixed up with brogrammer racism and sexism. But what keeps me out of spaces that attract people like this is that I’m tired of being erased, silenced, and talked over. When I say how uncomfortable I feel when someone is engaging in homophobic hate speech at my workplace, and I’m told that it’s not hate speech or that my reaction to it isn’t real or valid, that’s stressful for me. It makes me want to disengage from the whole community. I’m tired of my female friends and colleagues getting death threats. I’m tired of being told I have a victim complex if I talk back to the abuse that gets directed at me and my friends even if nineteen out of twenty times, I’m silent about it. (It’s actually when I’m acting the least like a victim — when I’m not passively accepting whatever abuse is directed my way — that other software people shame me for “playing the victim”.)
The Mythical Manarchist-Month
While “On being a geek” was an appreciated summary of ground familiar to me, I found the “Openness” section more novel. I was pleased to see that Reagle opened the section by referring to Jo Freeman’s “The Tyranny of Structurelessness”, because Freeman’s article resonates with me strongly in light of last year’s troubles at Mozilla.
In my opinion, though, Reagle leaves a few dots unconnected in his discussion of “‘bad apple[s]‘ and ‘poisonous people'”. If it’s really a minority of the community that (quoting our own Terri Oda) “actively hinder women’s participation by trying to derail discussions, make contributions significantly more time-consuming, or send inappropriate or even violent private messages to contributors”, then why are they allowed to effectively dominate the community by putting pressure on women to leave whenever they feel like doing so? I think it would be doing a disservice to everyone to ignore the role of the majority of male contributors in the community, who stand back and watch, who fail to exercise effective moderation in discussion forums, who lack the courage to confront other men who are being actively sexist. It is also a disservice to everyone to ignore microaggressions. The ultimate effect of death threats or a constant stream of little reminders that no one feels obligated to include you (like co-workers addressing a mixed-gender group as “guys”) is to make out-group members feel like they’re just not wanted. “Good” people (people who think of themselves as tolerant, polite, and considerate), not just toxic “bad apples”, can engage in microaggressions. And even “good” people often get unnecessarily defensive when called on behavior they weren’t aware was a problem. There’s a fine line between recognizing the disproportionate power of a small number of belligerent people in the open-source community, and using that an excuse for other people to do nothing in response.
The section titled “Ideology” is perhaps the most challenging one to the cherished beliefs of open-source participants about themselves and their role in the political economy — Reagle tallies up a damning list of open-source idols (Stallman, Raymond, Wales…) and their Randian beliefs that would be amusing if we weren’t talking about men who so many people take seriously. Reagle’s insights on how an anarcho-libertarian ideology lends itself neatly to justifying the rightness of the existing gendered power structure are sorely needed. But again, I think he could have gone a bit further. The thing about freedom, at least the way it manifests today in open-source communities, is that it looks a lot like freedom from accountability, without freedom from the very real constraints that burden the many. It’s free as in freedom, not free as in beer, but I’ve started to hear “free as in free from consequences” when I hear open-source people use “free speech” as a reason to be abusive. It’s customary in both open-source and closed-source programming to use the legal mechanisms of licensing and copyright to absolve oneself of all consequences resulting from bugs in one’s software, as per the quotation from the GPL that I opened with. This is not where I want to debate the merits of that approach to the profession of engineering — I do want to ask what happens, though, when a programmer extends that approach to licensing into his personal life. What happens to a community when many of the individuals in it assert their right to “free speech” and thereby claim entitlement to shift responsibility for the consequences of their actions? Typically, when people feel entitled to make others pay the cost for their choices, the people who end up paying are people who the underlying social power structure places as subordinate. I’m using the pronoun “his” because people who are not socially recognized as men (specifically, white men) simply lack the power to do this.
One example of this freedom from consequences is the refrain that so many of us who speak out have heard, over and over, from our colleagues: “Have I offended you? Then the problem is that you’re so easily offended. Your feelings are your responsibility, and I have no obligation to not offend you. No one has the right to not be offended, and anyway, I’m an equal-opportunity offender, so if other people can take the heat, why can’t you? It must be because there’s something wrong with you. You really ought to lighten up, take a joke, get a sense of humor, not let those words have so much power over you, be less sensitive.” (The routine has become so standardized that Derailing for Dummies, as well as the Geek Feminism Wiki, catalog it.) How can these incantations of emotional blame-shifting be unrelated to the disclaimer of responsibility that appears in the GPL and other software licenses? If what characterizes the professional culture of software engineering is our refusal to own our work, what characterizes the after-hours culture of programmers is a refusal to own our words. It’s a culture of solipsism that makes minority group members into objects, designating people in the out-group as dumping grounds for the majority’s animus and need to mock the less powerful. Demanding that another person “be less sensitive” is rude, yet gets treated as polite. And because already-privileged people who make such demands get rewarded further (beginning with social acceptance), there’s little incentive for them to practice empathy.
The egocentrism I’m talking about isn’t just about dynamics between men and women. For example, Linus Torvalds’ public verbal abuse of Linux kernel contributors is an example of how open source culture also tolerates abuse directed by men at other men. (Sometimes it doesn’t just tolerate it, but even encourages it, as when bystanders comment “well, assholes get things done.”) Social hierarchies and displays of dominance are certainly alive and well in how men interact with each other; and because hackers often define themselves as beings of pure rationality and logic, they rationalize these hierarchies as “necessary” for “getting things done”. (I think we could also “get things done” if we recognized and accepted that as humans, we frequently act for emotional rather than purely “logical” reasons — and maybe even if we accepted that the dichotomy between emotion and reason is a false one.) That, however, does not mean that verbal abuse between men is just as intense for the recipient as verbal abuse directed at women by men. It doesn’t mean that verbal abuse between men gets excused as easily as abuse directed as women. And it doesn’t mean that there as just as many opportunities for a man to exploit another man’s vulnerabilities as for men to put women in their place. It could hardly be otherwise, given the wealth of experiences that women bring to interactions with men, of internalized messages that (even for those women who have worked hard to unlearn them) tell them that they deserve whatever abuse they get, that they really had it coming. It’s not that abuse is ever acceptable when directed at anyone of any gender. Rather, it’s that being punched in the face feels more intense than being tapped on the shoulder.
Ultimately, we have to ask whether the freedom to abuse people is one of the freedoms we value. Richard Stallman himself identified four freedoms when it comes to software: “the freedom to run the software, for any purpose”; “The freedom to study how the program works, and change it so it does your computing as you wish”; “The freedom to redistribute copies so you can help your neighbor”; “The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes.” (He notes that for the second and fourth freedoms, access to the source code is a prerequisite.) The freedom to be an asshole does not appear on this list. Rather, these values point to inclusivity (the freedom to run the software, as in: to be included in the community of people who get to use it) and altruism (helping your neighbor; helping the community by distributing a better version). (Perhaps the inclusivity part is a bit of a stretch — the freedom to participate does not explicitly appear, which may say something about what Stallman took for granted.)
Decades before, Franklin D. Roosevelt spoke about another set of four freedoms: freedom of speech and expression, freedom of worship, freedom from want, and freedom from fear. How often do you hear stereotypically privileged open-source guys talk about freedom from fear? As I’ve discussed, much of the dialogue that happens when hacker culture talks about diversity and inclusion is about laughing off the idea that anyone else’s fears might be reasonable. Likewise, techno-libertarianism has very little room for a discussion about freedom from want. There isn’t much time and space in hacker culture for freedom of worship, either — especially when you take a broad view of what “freedom of worship” means and interpret as freedom to believe in things that can’t be proven with logical rules from empirical facts (like the dignity and worth of each human being), without being punished for it through ostracism or in any other way.
In either case, “freedom to treat other people as if they don’t have feelings, or as if their feelings don’t matter” is not on the list. (Thanks to Leigh Honeywell for pointing out Stallman’s and Roosevelt’s four freedoms, and the parallels between them, to me.)
Diversity as Devaluation
I want to ask a question outright that Reagle at best hints at: Is the very nature of open-source, its fundamental ideologies and values, inherently bound up with the insulation of oneself from the collaborative social project of making progress towards equality?
Maybe the whole system by which people produce free and open-source software is designed to provide the same sort of cozy lifestyle that one can find by being a programmer writing proprietary software, but without all those nagging structures of accountability that one finds in the corporate world. Like policies against harassment and discrimination. It’s true that companies adopt those to protect themselves against lawsuits, not to be morally correct, but they do protect people. And open source is a world without that protection. Maybe comparing open-source and corporate proprietary software is the best experiment one can do to determine what measures attract or repel participation by women. We know that open-source projects have an even more lopsided gender balance, as a general rule, than proprietary projects mainly composed of people being paid by a corporation to work on them. Can that really be a coincidence?
In a community with no formal governing structures, it’s far easier for people to take advantage of whatever privilege and power they inherit from the underlying society. One form this power takes on is that of speech acts that dehumanize and objectify people, and appeals to “freedom of speech” to immunize the speaker from the consequences of their speech.
I think that the desire to make boob jokes with impunity is not the only reason why male open-source programmers would want to keep women out, though. After all, the sexist jokes and comments that tend to engage the “free speech” defense the most are rarely funny or interesting. I think sexist jokes and comments are actually a means to an end, not an end in themselves. We know that male-dominated professions tend to be more socially prestigious and more highly paid than female-dominated or even gender-balanced professions. This can’t be an accident; men’s social over-valuation and their disproportionate participation in work that people think of as important form a positive feedback loop. For example, consider doctors and nurses: no doubt, women originally got tracked into nursing since medicine wasn’t considered an appropriate profession for a woman (gotta keep that power out of the hands of women). But even now that women have been allowed to study medicine for quite some time, nursing continues to be a lower-paid and less-praised profession, in large part (as far as I can tell) due to the significant presence of women in it.
The thing about prestige-as-male-domination is that it’s fractal. For example, within medicine, it’s common knowledge that primary care providers are likely to be women, while doctors who work in the most prestigious and highly compensated specialties (e.g. neurosurgery) are more likely to be men. Likewise, within computer science and software engineering, both of which are male-dominated as a rule, it’s harder for women to gain entry into some fields than others. Anecdotally, those fields (within academic CS) are theoretical computer science, programming languages, and operating systems. Among non-academic programmers, open-source programming (especially systems programming) occupies the role that theory, PL, and systems do within academe: looked up to and highly valued. By contrast, self-styled expert programmers tend to disdain jobs in areas like Web development and quality assurance — that’s “women’s work”, to the extent that any software jobs are. Technical writing, as an occupation, is even more looked down on and even more open to women. Perhaps that devaluation is part of a more general distaste among programmers for documentation, which could allow outsiders to glean the in-group’s secrets. Writing documentation is also a form of teaching, which is also a traditionally female-coded profession, and also a profession that’s frequently looked down on. So that’s why it’s so important for men in the high-status subdisciplines to maintain their status by making sure women don’t enter and devalue their field. Keeping women out means keeping salaries high.
(Statistics backing up what I just claimed about medicine — at least for the US — are available from the Association of American Medical Colleges (PDF link): see table 3 on page 13, “Number and Percentage of Active Physicians by Sex and Specialty, 2007″. The only specialty that’s majority-women is pediatrics; cardiovascular disease, neurological surgery, orthopedic surgery, and a few other specialties are over 90% men. I don’t know of any similar reports about gender distribution (and salary distribution) within different areas of the software industry, so I don’t claim to be speaking any more than informally, based on what I’ve heard over the years.)
“It’s amazing the things women did to advance computing before it advanced to the point that we learned women don’t like computing.”
— Garann Means
Before computers were machines, computers were women. Most of us know that part of the story. What I know less about, personally, was the specifics of the process by which men drove women out of the profession of computing as it, well, professionalized. I can guess that white middle-class dudes saw an easy desk job that potentially would pay well, and the rest is history. Without evidence (at least not any that I have handy right now), I claim that none of this was an accident. Expelling women from computing was essential to the historical process of the professionalization of software and hardware engineering. (I know that that’s roughly how it went down with the profession of medicine, as documented by Kristin Luker in her book Abortion and the Politics of Motherhood: as “scientific” medicine arose, mostly-male doctors needed a way to push mostly-female midwives off the scene, and one of the ways they did that was by inventing the supposed immorality of abortion as a wedge issue.) For many men, a job just doesn’t have as much value if it’s a job that many women do too. And numbers don’t lie: jobs in male-dominated professions literally do have more financial value than jobs in more equal or female-dominated professions.
So arguably, open source is not just a different way to produce software. It’s also an experiment in building an alternative economy for status and peer review. At the same time as for-profit companies began to look harder at how to diversify themselves, how to create policies that would protect workers from sexual harassment and various forms of discrimination, the open source movement gained more and more momentum as a way to recreate all of the good bits of being a software engineer in industry (high social status, freedom, and money) without those annoying parts like human resources departments, processes, accountability, and rules (mostly rules to protect less-powerful members of the community). I don’t think that’s a coincidence.
There’s one misinterpretation of this section that I’d like to head off before it starts. I’m not suggesting that some nefarious group of patriarchs got together, had a meeting about how to exclude women, and disseminated the memo in a lockstep, hierarchical fashion. That’s not how it works. There is no intelligent designer or invisible hand that makes sexist decisions — rather, sexism is an emergent and self-reinforcing pattern that arises from the choices of many individuals. Just as organisms in nature behave in predictable ways without there being any central evolution planning committee, people who study societies have observed that groups of humans often act out predictable patterns too. Of course, sociology and anthropology have different methods and different standards of evidence than biology and physics do, but the social sciences are the only tool we have for rigorously analyzing how groups of people operate. It would be silly and anti-intellectual to discard these disciplines in favor of nothing just because they aren’t like physics.
Finally, a note if you’re asking “where does the money come from in open source?”: more than a few businesses pay engineers (often quite well) to work on open-source software for either part or all of their working hours. (I work for one of them!) In addition, open-source work is frequently a gateway to lucrative jobs and to the kind of social connections that make it possible to found startups. “Free as in freedom” doesn’t mean people work for free, and seemingly more often than not, they do anything but.
Reagle ends his meticulously researched piece with a conclusion that appeals to me as an intersectional feminist: he says that to achieve the goals of openness of diversity, we can’t just focus on openness and diversity as goals (any more, I might add, than an individual can live a happy life by resolving to strive for happiness); we can’t make things better by focusing on a single axis. Just as severe gender imbalances are a symptom of a broken community, addressing root causes will increase diversity as a side effect. But we can’t ignore gender (or race, class, sexuality, or ability), either. Responding to Kat Walsh’s writing about Wikipedia, he says, “the language of being ‘more open and diverse in general’ is problematic. Seemingly, there is no ‘in general’ yet when it comes to notions such as ‘geekiness’, ‘openness’ and ‘freedom'”. I agree — during last year’s code of conduct discussions at Mozilla, some people protested the idea of what they saw as a bureaucratic document codifying standards of behavior with “Can’t we just all be nice to each other?” But being nice, as many people construe it, includes subtly undermining the value and place in society of women and people experiencing a variety of other intersecting oppressions. Likewise, the concepts of “geekiness”, “openness”, and “freedom” will not magically lose their gendered connotations — we have to actively work at it. We can’t build a world where gender doesn’t matter by pretending we’re already there.
Hacker culture is a personal topic for me, so my own conclusions can only be personal. When I was 16, I saw geek culture as something I had to become a part of because I didn’t know any other way to be the person I needed to be. Now that I’m 32, I’m increasingly afraid that it’s something I have to leave in order to be the person I need to be. I know now what I didn’t know when I was 16: that I can be free from constant misgendering, no matter what job I do. I also know what I didn’t know then: I need to be somebody who is kind, patient, willing to admit he’s wrong, and able to make space for other people to join in. I’m not sure if that’s compatible with being in the open-source community, while also having self-respect, dignity, and a place at the table.
Where this is more than just my personal dilemma, though, is that once, I wanted passionately to write open-source code, and now it’s a struggle for me to keep going; not because the nature of the work has changed (on the contrary, it’s gotten more fun as my understanding of it has deepened and my confidence has grown), but because either the culture has changed or I’ve become more aware of its shortcomings (or both). Wouldn’t you want to know about it if you were driving away potential contributors — or forcing them into impossible trade-offs? I don’t think anyone should have to choose between doing good work they love and feeling valued and respected as a human being.
Thanks to GF contributors Leigh, Skud, Sumana and Shiny; as well as Graydon Hoare, for their comments. Thanks to Debra “Teacake” for linking me to the statistics on gender distribution in medical specialties.
ETA Wed. Feb. 6th: Joseph Reagle posted a response to the responses, which is also worth reading.