How Implicit Bias Impacts Open Source Diversity and Inclusion
“Although these unconscious biases are often not intended, the harm of them affects not only the individuals but the community at large.”
Explicit biases are easier to identify and call out. But, in a community, the implicit biases that developer advocate and technical writer Anita Ihuman speaks of act as death by a thousand cuts.
The lead of the diversity and inclusion badging review process for the CHAOSS project spoke at KubeCon+CloudNativeCon Europe virtually from her home in Nigeria, in order to address these biases that permeate open source. After all, we know that open source has far less diversity than the tech industry as a whole.
Hopefully, open source leaders and contributors will learn from Ihuman’s advice to both recognize unconscious biases as they inevitably crop up in their communities, as well as have the capabilities to address them.
Why Diversity and Inclusion Matters in Open Source
“In open source, when we’re referring to diversity and inclusion, we’re referring to an environment where everyone, regardless of their beliefs, race, background, nationality and appearance, feels equally welcome to participate, feel equally welcome to interact with other persons, and also make good impacts or contributions within the communities that they are actually a part of,” Ihuman explained.
Open source is built on the collaborative efforts of different individuals, so this really matters.
Diversity and inclusion within open source communities is linked to several benefits including:
- Project outreach to new contributors
- Project sustainability
- Increased productivity in team performance
- More diverse and creative skills
- Diverse perspectives drive innovation
But then, knowing these benefits, why do open source communities continue to receive feedback from those underrepresented that they don’t feel they can actively participate? What are the challenges they face?
The Different Types of Bias to Battle
Bias, Ihuman explains, is a prejudice held by an individual, group or institution, in favor of or against another individual, group or institution. It usually involves a comparison, in a way that’s considered unfair, causing negative or positive effects on the targets. Biases can be explicit or conscious, as well as often unconscious or implicit bias. The latter is the focus of Ihuman’s talk, those implicit biases that have been implanted by our individual and collective experiences and stereotypes.
“In most open source communities, there was a trend of domination of Western male developers, compared to women, people of color, parents, non-technical contributors, physically challenged people, people from marginalized groups and those who are not experts in the developer fields,” Ihuman observed.
In fact, in still the most in-depth open source diversity survey of its kind, the 2017 Github survey found that 60% of those from marginalized groups “indicated interest that they would love to contribute to open source projects, however, they are significantly less likely to because of the reception or the way things are carried out in the individual communities,” Ihuman cited in her talk.
Most of the time, people from these groups are motivated to participate and projects are motivated to receive more participants, but somehow there’s a disconnect in open source communities when it comes to recruiting new contributors that aren’t white and male.
Kinds of Implicit Bias Pervading Open Source Communities
To create a baseline definition and to help KubeCon attendees recognize their own unconscious prejudices, Ihuman broke down the many kinds of implicit bias that are both inherent to humankind and inherent to open source communities.
Halo Effect – the tendency of treating people positively in a way that influences judgments. This halo effect and all the positive news you heard about someone or a group, Ihuman said, overshadows any reality or negative impressions they’ve made on you or anyone around you. As we’ve already talked about, this halo effect can pose a real threat to security, as it can distract from signs of malicious injections made under the guise of preferred, known contributors.
Horn Effect – The antonym of the halo effect, it is by default thinking negative things about a person or group because of all the negative things you’ve heard before.
Confirmation Bias – when we favor information that fits in with our pre-existing beliefs, regardless of the truth. Ihuman gave the example of her own confirmation bias she got from TV that all Asians are better at math and science.
Gender Bias – Tendency to prefer one gender over another, like in politics when masculine is preferred.
Affinity Bias – The tendency for people to connect with those who share similar backgrounds, experiences and instances. Self-segregation by race is a common, visible example. As we’ve already written about, affinity bias runs rampant in open source communities — and the tech industry as a whole — which finds cis-gendered white men aligning with other cis-gendered white men.
Name Bias – Placing judgment on how a name is spelled or pronounced, typically showing a preference for Anglo-Saxon names. Name bias creeps into many hiring processes, as well as could affect how maintainers consider pull requests.
Appearance Bias – Favoring someone based on certain physical features that are typically similar to your group. These beauty standards are typically grounded in white supremacy.
Sexuality Bias – Another name for heterosexism, this means treating people differently based on their sexual orientation. “Sometimes people in open source say they do not actually own up to their sexuality in communities. They just make the contributions and go, simply because they have done this in the past and the treatment they received was not fair, and so they did not want to repeat this same experience.” Ihuman continued that this happens often, but other community members remain unaware of it.
Conformity Bias – Behaving similar to and agreeing with those within our group, even if it contradicts our own opinion or best judgment. Conformity bias amplifies the other types of implicit bias.
“Even if it contradicts our opinions or our beliefs, we still tune in anyway. A simple instance is where we always go with how the majority votes, regardless of what the results might be, always going with the group with the highest number of votes, the group with the largest say, the group that actually takes the largest share,” Ihuman said. This is usually the most represented group.
Signs of these different kinds of implicit bias that often people are unaware of but that often pervade communication in open source communities include:
- Microaggressions
- Unequal treatment
- Assumptions and stereotyping
- Double standards
The Impact of Implicit Bias
Implicit bias thwarts the nature of open source because open source is a place where we have to rely on the collaboration of different individuals and different groups. If we eventually let this implicit bias take the best of us, we definitely block out the ways for other people to get on board and try to collaborate on a particular project.
Implicit bias has people following specific patterns, Ihuman warned, like when a community hosts an event and, year after year, follows the same format to recruit speakers. Manels run rampant.
Any kind of implicit bias can create unfair disadvantages, like overlooking people from other groups for a particular position or opportunity within the community or the workplace.
Implicit bias also has a negative effect not only on an open source community but on those with these inherent prejudices themselves because, Ihuman says, it blinds people to the creative and innovative ideas of others.
“For instance, you are building software and you do not consider the accessibility. But someone who has some form of a neurological challenge notices accessibility issues within your software,” and easily points to a solution, Ihuman said. But the inherent bias within may have project leadership to disregard this need or solution.
Overall, these biases can contribute to unhealthy environments. And people talk, sharing their negative experiences. The perception of a community can change quickly, based even on just one person’s account.
Without a strategy with inclusive practices within an open source project, communities fail to reap the benefits of all forms of diversity and even fail to notice that potential.
“We should care because we are humans and there is definitely going to be those differences among us, no matter where we are,” Ihuman said, arguing that open source communities and especially leadership have to work on their communication to support and even honor those differences.
This inclusive mindset and action plan, she continued, is essential in maintaining a community-first mentality, where empathy is essential. After all, open source has more eyes and more ears than most other projects, which means the individual effort and the individual experience matters, maybe even more.
“It is impossible to actually have a healthy community without taking note of some of the things that are maybe affecting the health of that particular community at large,” Ihuman said.
“It affects us all,” she continued. And experiencing this implicit bias negatively affects everyone.
How to Address Implicit Bias within Your Community
Awareness is of course the first step to addressing biases within the communities you’re a part of. Ihuman recommends kicking off this journey of self-exploration by taking the Implicit Association Test or IAT.
Challenges will arise in any community. As an open source leader, examine how the interaction went down and how both sides react. Evaluate, she said, if there is a way to remedy the situation.
“A lot of times, perpetrators are unaware of their actions, so it’s very good to educate your community about these biases,” Ihuman continued. And encourage team members to speak up when they feel harmed by biases or have witnessed harm against other community members. Aim to settle it amicably and privately, when possible, she recommends, citing Conventional Comments as a good way to hone feedback-giving skills.
Open source communities, she recommends, should set diversity and inclusion goals and be intentional about them. The open source project she works on CHAOSS is dedicated to community health analytics. Let data inform your decisions, she continued.
One of the most important pillars of open source diversity and inclusion is the code of conduct. Ihuman recommends to even go beyond that code of conduct. These guidelines should include explicit examples of what should and should not occur within the community and include repercussions if they do. When members speak up about negative experiences, there must be consequences.
Remind community members of the code of conduct regularly, not just a box to check before the first contribution.
Finally, Ihuman recommends taking the lead by creating diversity and inclusion focus groups. Concentrate on measurable, incremental improvements that contribute to project sustainability:
- Talent retention
- Contributor satisfaction
- Productivity
Just make sure that your D&I strategy is not generalized, but rather customized for your community and the sub-groups within it.
“Attaining virtual workplace diversity and inclusion takes a group effort. It doesn’t take one person to ship all of this. But if every single person makes an effort, at the end of the day, we’re definitely going to get a more inclusive, welcoming open source community,” Ihuman closed with.
