Diversity and inclusion: Stop talking and do your homework

Mozilla's research uncovers important ways to promote diversity and inclusion in open source projects.
648 readers like this.
Lots of people in a crowd.


Open source undoubtedly has a diversity problem. In fact, tech has a diversity problem. But this isn't news — women, people of color, parents, non-technical contributors, gay, lesbian, transgender, and other marginalized people and allies have shared stories of challenge for years.

At Mozilla, we believe that to influence positive change in diversity and inclusion (D&I) in our communities, and more broadly in open source, we need to learn, empathize, innovate, and take action. Open source is missing out on diverse perspectives and experiences that can drive change for a better world because we're stuck in our ways—continually leaning on long-held assumptions about why we lose people. Counting who makes it through the gauntlet of tasks and exclusive cultural norms that leads to a first pull request can't be enough. Neither can celebrating increased diversity on stage at technical conferences, especially when the audience remains homogeneous and abuse goes unchallenged.

This year, leading with our organizational strategy for D&I, we are in investing in a D&I strategy for Mozilla's communities informed by three months of research.

Mozilla diversity and inclusion research findings


Following are early recommendations emerging from our research.

Build and sustain diverse communities

1. Provide organizational support to established identity groups

For reasons of safety, friendship, mentorship, advocacy, and empowerment, we found positive support for identity groups. Identity groups are sub-communities formed under a dimension of diversity, such as language, gender, or even a specific skillset. Such groups can act as springboards into and out of the greater community.

2. Develop inclusive community leadership models

To combat gatekeeping and the myth of meritocracy, community roles must be designed with greater accountability for health, inclusion, and especially for recognizing achievements of others as core functions.

3. Implement project-wide strategies for toxic behavior

The perceived risk of losing productivity and momentum when addressing toxic behavior is shown to interfere with and risk community health. Insights amplified by HR industry findings show that, although toxic individuals are often highly productive, their cost in lost productivity far outweighs their perceived value. Strategies for combatting this in open communities should include cross-project communication about such decisions to avoid alienating or losing contributors.

4. Integrate D&I standards and best practices into product lifecycles

Extending on the notion of cross-project collaboration is the strong sense that building D&I standards into product lifecycles would benefit maintainers and community leaders, create reach, increase collaboration, and break down silos. An analogy is how web standards enable open communities to build on one other's work across various open ecosystems.

5. Build inclusivity into events

Project and community events, although trending in positive directions by putting diversity on stage, struggle with homogenous audiences, unclear processes for code-of-conduct reporting, and neglect of neurodiversity issues. A series of recommendations is coming based on this research, and Mozfest has done a great job in past year of building inclusiveness into programming.

Design models for accessible communication

6. Break the language barrier

Quantitative research showed only 21% of our respondents spoke English as a first language. Prioritizing offering all key communications in multiple languages, or providing transcripts that can be easily localized, is important. The intersection of language and other diversity issues raised almost impossible barriers (for example, a new mother whose first language isn't English runs out of time translating a presentation made in English).

7. Generate diverse network capabilities

Contrary to the spirit of openness, many (if not a majority of) projects are working on similar D&I problems—with learning rarely shared between, or even within, communities and projects. New generations of community managers and leaders identify the same issues—and begin again. Later this year, we'll propose an initiative to bring together learning, document ways to build communication, and collaborate towards innovation desperately needed to move the needle in D&I.

8. Experiment with accessible communication

In our interviews, we were surprised to learn that text-based interviews were preferred not only by those with limited bandwidth, but also those who identified as introverts, preferred anonymity, or have a non-English first language. The simple act of changing the way we talk to people can have wide-ranging impacts, so we should experiment often with different modes of communication.

9. Avoid exclusion by technical jargon

Technical jargon or lingo and overly complicated language were cited as critical challenges for getting involved in projects. Our data shows that technical confidence might be influencing that barrier, and men were nearly twice as likely to rate their technical confidence highly. These findings indicate that it's critically important to limit jargon and to shift from technical posturing to empathy in participatory design. Rust is working on this.

Frameworks for incentive and consequence

10. Mobilize community participation guidelines

In recent conversations with other open project leaders, I've realized this is a pivotal moment for open projects that have adopted codes of conduct. We're at a critical stage in making inclusive and open project governance effective and understood—making it  real. Although enforcing our guidelines sometimes feels uncomfortable and even meets resistance, there are far more people for whom empowerment, safety, and inclusion will be celebrated and embraced.

11. Standardize incentives and recognition

Although the people we interviewed want to feel valued, they also said it's important that their accomplishments are publicly recognized in formats with real-world value. It's worth noting that recognition in open communities tends to skew toward people most able to surface their accomplishments and technical contributions, which may exclude more reserved people.

12. Design inclusive systems that protect identity

Many systems do not adequately protect the information of people who register in community portals, and thus exclude or expose those who prefer to hide personal data for reasons of safety and privacy. The research showed a variety of non-obvious ways we ask for and store gender-identity information. D&I standards are a way forward in providing structure, predictability, and safety in systems, as well as mechanisms to track our progress.

More detailed findings on our research and path forward can be found on Mozilla's Open Innovation Blog.

Learn more in Emma Irwin & Larissa Shapiro's talk, "Time for Action—Innovating for D&I in Open Source Communities," at Open Source Summit, Sept. 11-14 in Los Angeles.

User profile image.
Open Innovation Team, Community Development @Mozilla , Previously Participation Architect @Benetech #FOSS #OpenEd Web Dev, Mom above all other things. @sunnydeveloper



>Stop talking and do your homework.

Clearly. You in Silicon Valley, You really need a lot of real competition. Based on meritocracy and not on something else.

I don't live in Silicon Valley, and Meritocracy is a myth.

In reply to by Exactly (not verified)

No, it's not. It is what made Open Source great. It's an integral part of it's canon (should I quote?). What is a myth is your PC babble. And that link to this "meritocracy debunking blog" is mrrely an incoherent, badly researched joke.

In reply to by sunnydeveloper

I'm sorry, anyone who can/want can contribute to open source projects.

I haven't seen ever a single project where "women", or "minorities" are told, no, you can not contribute.

Perhaps your problem Emma is that open source projects resist political control attempts from "women" or "minorities", isn't it what the problem is about Emma?

Code more and do less politics.

Hi John,

I suggest you, really focus on the title of this post and do your homework. This not about an obvious 'sign out front' deterring women and, this is about deeply understanding the ways we exclude diverse people, perspectives and thus true innovation. Do you want people to code more, in an innovative way? In a way that improves the world? Or do you want them to code more - in a way that keeps everyone in their designated places that make you feel most comfortable? John, keeping things comfortable for you, is not a political move. Please do your homework.

In reply to by John Sanders (not verified)

The focus on code above all else may be the biggest shortcoming of open source communities. Software is fundamentally about solving problems for people, but too often open source projects get caught up in code as the end instead of the means.

In reply to by John Sanders (not verified)

Mention ONE open source application that was successful without ANY coding. Now mention an open source application that was successful with coding only (no website other than Github or Sourceforge, no documentation and no artwork). I think the latter task is essier than the former.

In reply to by bcotton

Open Source doesn't have and never had a "diversity problem". In fact, those who claim we have, have been insulting and harassing hard working programmers for years - with anecdotal "evidence" at best. And it has to stop. Note that about 25,000 FOSS projects are one-man projects. And only 5% (at best!) are occupied by women. Explain away that one. How you are (sexually) harassed when you are a one man project. Or that MOST of the jobs women occupy in FOSS have very little to do with programming (hence the lack of one man projects). May be it has to do with the fact that the vast majority of programming magazine audiences have been male (in the same sense that the vast majority of Elle and Vogue readers are female). So - and I stated that years ago - if women want to participate, get rolling. Don't spend much time on brown paper sessions "Why are there so few female programmers", simply start coding and get of the back of the people who actually ARE coding.

No, there is no diversity problem, simply because it can't exist. As Geoffry Miller put it: "If different groups have minds that are precisely equivalent in every respect, then those minds are functionally interchangeable, and diversity would be irrelevant to corporate competitiveness". It's either or. Take your pick of ideology.

Just because a person is the sole developer on a project, that doesn't mean they can't be harassed (sexually or otherwise). Sole developers still interact with other people, be they users, upstream projects, downstream projects, conference attendees, etc. The lived experience of many women in FOSS disprove your "it's impossible" assertion because it has happened to them.

In reply to by Hans Bezemer (not verified)

That's pure humbug and you know it. Most single person projects are done in the attic. And you don't have to go to conferences - I never did and since the SJW took over I probably never will (that's the talent you're discarding by making a political stand - smart!). And I'm sick and tired of you coming up with "real experiences of real women". Anecdotical "evidence" was and will rightfully never be a valid argument, because you know what? Anybody can come up with an anecdote (actually I once did - I wrote an entire blog with "other experiences of real women" to prove the point of the fallacy of anecdotical "evidence"). And you know what? It happens to us men too. Like me. I can show you the emails. And you know what else? I didn't throw the keyboard out of the window and went weeping to my mummy because THAT IS LIFE. If you're having thousands of users, there will be some jerks. If you're suggesting that women are such fragile beings that they can be put off by such an experience from doing what they do love best, then there are two possibilities. First, if that is the case then may be they shouldn't go out into the real world, because it will simply be too much for them. Even men get burn outs. Second, my wife has worked on a call centre and was daily verbally abused. She would be insulted by what you're suggesting. Maybe this will help you to see the light. Go on the street and try to recruit women to be a model. Then try to recruit them to be a programmer. See which crowd is bigger.

In reply to by bcotton

Let me address a number of points:
- Break the language barrier: "Prioritizing offering all key communications in multiple languages"

Surely you do realise that the vast majority of FOSS projects are hard pressed to find enough contributors to document even in English? Where are all these translations going to come from?

- Avoid exclusion by technical jargon: "Technical jargon or lingo and overly complicated language were cited as critical challenges for getting involved in projects. "

While overuse of jargon where unnecessary can be a problem for all people, jargon is a necessary evil in all technical fields. I don't see why this would be a particular problem for anyone that isn't a white man. If you don't know the jargon, then you probably don't know the subject. If you don't know the subject, then you're probably not going to be much use.

- Design inclusive systems that protect identity:

I would argue that this is one of the biggest issues in the online world. If you wish to contribute to a FOSS project, you must be trusted and for that you need to be known. On the flip side of the coin, anonymity permits online abuse to be a consequence free pastime. Try exposing online abuse if you don't know who the abuser is.

I would say that the online world is an unforgiving place and by and large I do not participate in it much, preferring more private channels of communication. Social media brings out the worst in all genders and creeds.
However, if you wish to participate in software development, you have to know your stuff. If your contribution is not up to snuff, then you are going to receive criticism. If you cannot take criticism then you will not find the FOSS world a very comfortable place.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.