Beat Affinity Bias with Open Source Diversity and Inclusion
Loads of open source software (OSS) communities sport rainbow-fied logos for pride, tag #BlackLivesMatter and #MeToo, and do a lot of other performative posturings. Yet numbers teeter at around 3% of OSS contributors identifying as women, compared with about 20% of the overall tech industry.
Women in open source play the canary in the coal mine, alerting to bigger diversity problems endemic to the ecosystem. Other OSS demographic data are abysmal, too, including that, while Africa represents 16% of the global population, it makes up just 2% of the GitHub community.
This past March, She Code Africa received 180 applications from women all over the continent for its open source virtual boot camp. But the non-profit could only find three OSS communities to participate as mentors, so they had to accept far fewer applicants. Sure, they got ample sponsorship funds, but only Jenkins, Layer5 and DeployHub were willing to donate their time, too.
So the lack of representation isn’t a lack of interest in OSS, and it’s not a lack of talent either. Last year’s e-Conomy Africa 2020 report found there are more tech workers in Africa than ever, which boasts more than 600 different tech hubs. Events like Open Source Community Africa, which saw more than 800 attendees from Nigeria and beyond, show that there is also a local demand for open source guidance.
But, as Zainab Abubakar, DevOps engineer at the Interswitch Group, technical writer for Jenkins, and open source programs manager for She Code Africa, said, “We’ve got great talents in Africa and I can boast of Nigeria in particular — what we need are opportunities. We’ve got a long way to go.”
And Africa isn’t unique here. Open source communities in the Global North are still slow to change their un-inclusive habits, including of women, and especially when other intersections like race, religion, gender, and sexuality are factored in.
Abubakar told The New Stack, in a follow-up interview to her talk at this year’s cdCon, that there are a lot of open source communities claiming to work on diversity, “but the truth is they aren’t actually doing enough.” This article is a mix of that conversation and talk.
In truth, a lot of the diversity, equity and inclusion initiatives in open source and the broader tech space remain highly theoretical and discursive. The needle just doesn’t seem to be moving.
“I think open source communities and organizations should put their money where their mouth is. If you are talking about encouraging more diversity within your community, it should be more than you just speaking at an event or writing an article. Communities need to take active steps to show that they are really doing things to encourage a diverse and inclusive community,” Abubakar said.
What we need is specificity. Action items to go beyond branding initiatives toward clear conduct policies and inclusion strategies. That’s what today’s piece is all about.
Why Open Source Should Be Desperate for Diversity
You could say the open source ecosystem isn’t desperate because Github saw a 25% jump in contributions in 2020. But we know it’s proven that increasing diversity and inclusion is linked to financial growth. In fact, it leads to better performance across several metrics including innovation, creativity and product quality and usability.
If open source is the predominant way the future is being built — with 90% of businesses using at least some OSS — then it is dangerously excluding the majority of its users from building and training that future. We already know that voice recognition software is worse at recognizing higher voices — even though most virtual assistants are femme by default.
And facial recognition software ranges from beheading Black people on Twitter and Zoom to inaccurately identifying dark-skinned women a third of the time. Stuff like this continues to happen because the developers of software and the data they are training on are dangerously un-diverse. You can’t build solutions for marginalized groups if they are excluded from the creation.
For Abubakar, her favorite benefit of open source — the community — really loses out when its members all look the same way and come with the same life experiences, perspectives and backgrounds. Community is the social capital of open source.
Of course, the open source definition specifically prohibits discrimination, so, not only can these groups not benefit from open source, a lack of diversity could threaten your open source license.
Hostility and Affinity Bias Plague Open Source Communities
“The truth today is that the achievement of women in the world is really undermined.”
So we know there are not enough contributions from women, and even that’s not wholly accurate as “women” is being used as a catchall for non-male and non-binary too. But, as program manager Emma Irwin wrote, “if a demographic representing nearly half the population on Earth fares so poorly, how will we ever progress in other areas of representation including non-English speakers, race/ethnicity, age, family status, socioeconomic status and dis/ability?”
Abubakar said, “The truth is women are often left out of group events or are consciously ignored because they are not a member of the ‘in group’ which in IT often means white men. Whether this is conscious or unconscious, it is definitely a bias, and it definitely makes it difficult to get involved.”
She said this comes down to affinity bias, the tendency to get along with and want to work with others like ourselves. For minoritized groups, this can be an important way to create safe spaces, but for those in a strong majority, like white men, that contributes to a dynamic where everyone outside that affinity is excluded.
She argues bias training should be mandatory for OSS maintainers and other community leaders.
Of course part of it could be the self-fulfilling prophecy of having a reputation for fostering toxic environments. Abubakar talked about the countless stories of questions and contributions being met with public ridicule.
“Breaking into a community that acts hostile towards members and outsiders requires a large amount of motivation and this tends to hamper people who already don’t fit into the mold of the traditional white male computer nerd,” she said.
But it’s not only a lack of empathy, it’s open sexism and hostility, ranging from inappropriate code feature jokes and appearance comments all the way to unabashed remarks on public mailing lists. And, as Abubakar, pointed out fighting to stop this is often met with extreme resistance, ridicule and retaliation.
For instance, the 2017 GitHub Open Source Survey, which unfortunately is still the most recent, in-depth examination of this issue, found that this kind of negativity drove 21% of contributors to drop out. About half of all respondents have witnessed this rudeness or harassment — which of course doesn’t factor in all the abusive DMs that go unseen.
We’re already written about how there’s a wide range of both anecdotal and empirical research that shows “hostile, discriminatory and predatory experiences of women and underrepresented minorities” in OSS. Abubakar reminds us that “All of these issues stand in contrast to what open source contributors want and what the open source community is meant to represent.”
Measure Misogyny and Misogynoir
The existing subconscious bias against women in open source communities is extreme — and quantifiable.
A well-cited study from 2017 examined the gender biases in open source by focusing on GitHub pull requests in open source projects by nearly 1.4 million users where the gender identity based on their profiles was apparent. They found that, overall, 78.6% of pull requests made by women were accepted compared with 74.6% of those made by men. However, among women users that were not well-known in the community, this acceptance rate dramatically dropped.
For those newcomers, who are not explicitly authorized owners or collaborators, the paper stated, “We see evidence for gender bias: women’s acceptance rates are 71.8% when they use gender-neutral profiles, but drop to 62.5% when their gender is identifiable.”
These results point to the fact that women’s pull requests have a higher acceptance rate than men’s, at all cadences of contribution, which implies that their work is deemed subjectively better. However, when gender bias factors in, they are negatively impacted.
Abubakar started contributing as the gender-neutral name Zaycodes in part to limit that bias. She says maintainers need to focus more on just reviewing the pull requests and the changes, without finding out who the person is and where they are from.
But then each project can still maintain an opt-in contributors’ list, to track your DEI work, including pull requests (approved and not), authored content, and number of contributions.
Abubakar reminded: “The truth is, it is difficult to totally eliminate the difficulty of diversity, equity and inclusion within the open source community. However consistent, the work and endeavor have no bounds. As a result, it is critical to be completely informed of this situation and to work as a team to achieve this common goal.”
Just try to always publish your results — it’ll make you more accountable and more likely to achieve your goals.
The First Step Is the First Step
“A diverse community, with contributors of all ability, makes a difference. You have the ability to make a difference in every community in which you operate by making a difference in the life of your employees.”
Abubakar says an open source project must welcome newcomers intentionally, setting expectations for both a community and its norms, creating a safe space to give and receive technical support early on.
She told The New Stack that much of this can be automated in an #introduction-channel that you auto-add new members to. You can even set up slack-bots to give people a step-by-step walkthrough of where to start, including pointing to the code of conduct and explaining its importance and the community’s commitment. Then the community manager can dedicate their time to signpost issues that are good starting points.
Abubakar said it’s not just what you share, but how you share it. Avoid overly technical jargon, especially in that intro channel. You can get to those technical terms, but in a glossary addendum to your documentation or linked throughout.
She pointed to the Jenkins community and how omnipresent “controller” and “agent” are — you not only encounter their definitions on Page One, Day One, you get explanations and a demo walkthrough. Even better if you explain everything in clear terms in different formats — written, audio, video with subtitles — so that different abilities and learning needs can access the same information. Things like written transcripts are also easier to translate to onboard other languages.
Consequences for Bad Behavior
Abubakar said that “We have a lot of open source communities these days that just have a code of conduct in a ReadMe file on their repository and people are going against this code of conduct, then nothing is being done. It’s very important that open source organizations enforce this code of conduct and ensure that anyone who goes against it is penalized or some form of punishment.”
She gave some strategies for communities to address toxic behaviors like bullying, stereotyping, name-calling, humiliation and harassment.
The first step should always be a public apology from the perpetrator, she said. As it escalates, she says the community leaders should enforce policy by means of a suspension. This may seem small, but, according to a survey of open source software developers that Tidelift and The New Stack jointly ran in 2019, on average, 40% of their time contributing to open source was part of their job. So any suspension or expulsion could risk said job.
“Where you are even being paid to work for that community, the responsibility and the accountability should even be more, like your normal job,” Abubakar said, then continued “though I think the pay doesn’t really matter, whether you’re getting paid or not, it is compulsory for you to go by the code of conduct.”
When asked if these violations should just be “kept in the community,” Abubakar said that goes against the whole point.
“When you say a community is an open source community, it means that almost everything that you’re doing in the community should be available to the public,” including your code and docs. “Because most likely whatever you’ve done, it’s been in the public. If someone makes a comment that is not OK, I think you should be able to call out the person in that same platform so that every other person in the platform understands and knows it’s not OK.”
But she says it goes further than that. “The most important thing is to be able to call the attention of the maintainers or go higher,” she said giving the example how Jenkins has other foundations that sponsor the massive project.
The Buck Stops with OSS Community Leadership
Abubakar says leadership sets the standard for values that should be strictly adhered to, backed by policies and codes of conduct. They should exemplify how to disagree properly, even over contentious issues like code checks on important features. And any violation has to be addressed as soon as possible or people will get used to it.
She continued it’s up to the community manager to reject and delete comments that sound insulting or abusive — but snap those screenshots first. This way you keep your receipts, but new members won’t see these unwelcoming or harassing comments.
Of course, a whole other issue is that there is a lack of role diversity and of recognizing contributions that aren’t logged into collaboration tools like code repositories.
Abubakar said it’s up to leaders to dispel prevailing myths including:
- You need to be a programmer to join OS. (There are many other ways to contribute.)
- The culture and norms of the open source community are easy to navigate. (Not always the case at all.)
- Feedback is readily available. (Often people don’t know how to contribute, improve or why their initial pull requests were rejected.)
- You can’t be a casual contributor — you have to work on an open source project for your entire life. (You can work according to your convenience and be a short-term contributor.)
“Coders get all the love,” she said, but community leadership should hold up other roles as just as important, including technical writing, community managers, question responders, marketers, designers, and program and product managers. After all, these are the contributors that actually make it easier for people to go from Hello World to repeat contributions.
And roles like translators allow for easy localization of the open source ecosystem, especially when only 21% of contributors to some OSS projects are native English speakers.
The best way to overcome affinity bias is by making sure all levels of leadership embrace both traditional diversity as well as role diversity. A community exists when everyone feels acknowledged.
Author’s Note: If there’s one thing for sure, while we know it’s a big problem, we also know that the industry needs better data and insights. The Linux Foundation just released its Diversity, Equity and Inclusion in Open Source Survey and we encourage you to share it and respond to it yourself.