“Females” in Open Source

For several years, I served as a board member of a certain city’s Linux Users’ group. They were a great bunch, always welcoming and friendly. My opinion was always respected, despite being the youngest member of the group by far. I was the only web developer amongst mostly systems administrators, and they valued my programming skills and unique experiences.

They were also predominantly white, and over 40. The board was also exclusively male (I was too, at the time). They recognized this lack of diversity and wanted to do something about it, so the question was asked:

“How can we attract more females to F/LOSS?”

Females?

For a moment, I was glad there were no women on the board. That way, they would not have grossly offended anyone and perhaps ruined their chances of actually accomplishing the goal of having some gender diversity. I would have a chance to keep them from shooting themselves in the foot, at least.

“Maybe start referring to them as women instead of females?” I said.

Reactions varied. There were nods of agreement. The man who originally raised the issue looked briefly surprised, then hung his head. One member rolled his eyes and agreed, as if he had thought of the same thing without knowing what to say.

CC-BY Richard Rutter, filtered.

Nonetheless, the goal was clear: we needed more representation of women on the board, and to figure out how to get it. Thoughts were searched, terms were googled, ideas were debated.

Maybe it was that our topics were boring to women. We knew that web development, UX, design, and other such topics had a much larger female demographic compared to our usual fare of systems administration and operating systems. We might present about web frameworks, Javascript, or the design of Linux desktop environments. Surely that would be more appealing.

But it felt cheap. We all agreed that women were welcome to any of our events and were equally capable in any topic we might discuss. There must be something deterring them from attending our existing events. Was it that there were only men in attendance?

Perhaps we could run a women’s-only event. Ladies Learning to Code had been successful in the past, and we had plenty of technical experience to lend. Why not hold technical seminars for women?

That was, simply put, impossible. There were no women on the board or even amongst the card-carrying members of the group. Being exclusively male, the group could not possibly create a safe space, no matter how much they wanted to.

So why not reach out to women already in technical volunteer organizations like ours? One of us discovered a women-only Linux group in a nearby city; why not reach out to them?

But how would that look? A bunch of 40-something men invite women to “present” to them to attract more women to the group.

“Hello, Mars need women!” The women’s-only group probably existed in part to avoid precisely these kinds of “advances.” If they were a technical group, they would want to talk about tech, not how female they were. We feared the worst of impressions, and eventually decided against reaching out to them on the topic.

In fact, we decided against reaching out in any specific way. We were at such a loss that the initiative was abandoned. If women were to join us, it would have to be as a result of wider promotional efforts.

A Wider Problem

It wasn’t just our group that suffered from poor representation. I attended a web technologies meetup held by a separate group and invited a friend of mine who had recently taken an interest in programming. I had taught her enough Python to solve entry-level interview questions and thought she might like to talk shop and hear about others’ learning experiences.

She had a great head on her shoulders, a fit figure, and a magnetic personality. Apparently, all indicators of not belonging in a technical group. “So, do you two have a financial arrangement or what?” they asked her in my absence. She avoided the insinuation as professionally as she could. Later, the other (male) attendees were surprised when she discussed algorithms and programming languages – how some were more intuitive to her, and how she was curious about others.

She didn’t join me the next time. I didn’t blame her.

I would later try again with different groups and different friends of mine. A more technical friend accompanied me to a casual meetup which I hoped would be better, but the men still made her uncomfortable. I directed another friend to a “ladies learning to code” event I had heard of, but she declined; the guest list was more than half men.

Even I was guilty of this. As I reflected on my own gender identity, I became increasingly aware of how I would reflexively present a more masculine persona at technical events. Despite the fact that it is easy for me to outwardly present as male and pass as part of the in-group, the problem was just that – I was passing. As I imagined how the women I invited must have felt, being discounted immediately on their arrival, previously unnoticed details became warning signs.

All-male guest lists. Guest lists with only one or two women, especially if they had RSVPed shortly after the meetup was announced; would they be showing up now that they knew how overwhelmingly male the event would be? Venues in neighborhoods with high crime rates. Events hosted at bars. No code of conduct, no policies of any kind. All things that seemed innocuous to my younger self, blinded by privilege.

CC-BY Tech Cocktail, filtered.

And so I considered the broader question: how did it get like this, and why?

The Linux Users’ group was demographically similar to other meetups, but could not find a way to show that they would not behave like their sexist neighbors. They were clearly more respectful: the board moved events for minority religious observances, our venues were always accessible, and people could volunteer to obtain a membership if they could not pay the dues. As far as they were concerned, the only thing a person needed was to be interested in F/LOSS; that was the sole qualification for their group.

This is something they genuinely believed as a core tenet of F/LOSS. “Free as in Freedom” applied to language, culture, gender, and identity in general just as much as source code. Prejudiced in-groups such as the worst of the meetups, however, hide behind the same belief. Events being “open to everyone” was a token political statement. If they didn’t recognize someone as being part of their in-group, all they had to do was make them uncomfortable. After all, that person is always “free” to leave.

The problem is also self-perpetuating: if a woman’s early experiences with meetups, technical events, or similar groups are bad, and they all look the same from a distance, they all look bad. Moreover, the benefit of the doubt is difficult and even dangerous to give, considering participation in these communities frequently involves walking into a room full of strangers. It is so pervasive that welcoming groups which simply happen to be started by men may inadvertently reinforce the existing monoculture; their accidental lack of diversity early on quickly appears to be deliberate.

“Apolitical”

This brought me to realize how difficult it is to accurately discern a group’s true politics without exposing oneself to danger. Bringing women to meetups was the best demonstration: while I would initially find the group approachable, their behaviour would change drastically when someone attended who they identified as a woman. Claims made publicly about what a group was became meaningless, much like the “ladies” event which was comprised of 50% men.

Consequently, the Linux User’s group’s good nature would hardly be seen by women; they would have to attend to know that they were actually quite welcoming, but with no way to discern this, women rarely attended. We naïvely thought we were a victim of the demographics of the tech industry as a whole: few among us were women, even fewer participated in meetups, and none of them had happened to join us. The same lack of awareness that made the group so unappealing in the first place made that explanation completely believable.

Perhaps the most frightening aspect of that error was how it deterred us from publishing our better inclusiveness policies in a useful way. The group was explicitly apolitical, and we feared entering such a polarized space. Besides the concern that we would seem condescending, there was sentiment that we would be seen as a rights group. While that would have been a gross violation of our apolitical stance, the fact that inclusiveness policies or supporting tech community minority groups might be seen as “political” in the first place is deeply disturbing. Since when was respect for others a political belief?

That is, however, the reality of the situation. Sexism is so deeply ingrained in tech’s unbalanced demographics that making a point of not being a misogynist is practically countercultural. Unseating those biases to the point where codes of conduct are normal and our spaces are widely safer will take huge forces of change. Men who are “fitting in” to tech culture will need to become allies. They will need more women to ally with. The industry as a whole will need to face these issues instead of being quagmired by the relative comfort of monoculture.

The Cutting Edge

Most of all, we need to self-examine: what are our personal policies about fair treatment and how do they interact with the reality of our communities? While we may, in principle, accept anyone into our communities, those people will never approach us without some assurance that they will be safe and have their contributions recognized. The most important steps in this process are to write down the “common sense” of the organization, adopt it as policy (be that a code of conduct, charter, or similar document), and publish it.

Each of these steps are critical. “Common sense” and standards of respect may be obvious to us personally, but they are invisible to prospective participants and, more importantly, unenforceable. Adopting these ideas as policy gives meaning to statements of inclusiveness. “Everyone welcome” is an idle threat; without qualification, an abusive or offensive person is just as welcome as anyone else. With policies adopted and published, expectations of behavior are created that will both deter abusive individuals and invite participants who are concerned about abuse.

When one is not in a position to make policy, we should invite our friends and colleagues to trustworthy groups. Growing participation in these groups is not only beneficial to the community directly, but making them successful lends influence in similar groups. With more successful, diverse groups in our broader community, other groups will (hopefully) model themselves more on their healthy dynamics of interaction. While it may be frustrating to think of respect as a popularity contest, progress will not occur without widespread support.

If I could try again – to be on the Linux User’s group board when this was being discussed – I would have pressed my peers to take a step back and consider how uncontroversial their ideas really were. It is a human right to not be judged on gender, orientation, race, or creed; repeating this in our group’s policy would be no political leap of faith. Groups, no matter how small, friendly, or informal, must codify this behavior and promote it until it is widespread.

There will come a day when we attain representation and fair treatment as a rule rather than an exception, but until then, we need to let our peers know when and where they will be safe and appreciated. If tech wants to continue to advance scientifically and economically at its historical rate, it will need to advance culturally first. We are supposed to be the cutting edge, after all.