Inclusion at Scale in the Mozilla and Kubernetes Open Source Communities
Traditional co-located organizations are struggling in their search to become more accessible, diverse and inclusive organizations. Not only is it the right thing to do but it’s proven to drive innovation. Now imagine the greater challenge facing massive open source projects that have thousands of distributed volunteers across a hundred countries in dozens of languages.
In 2017, Github surveyed open-source participants. Out of 5,500 participants, only three percent of respondents identified as female and one as non-binary. With about 23 percent of U.S. computer programmers identifying as female, the gender disparity in open source seems even more glaring than the rest of the industry.
How do you make sure everyone, regardless of age, gender-identity, language, socioeconomic status, race or ethnicity, family status, and availability to volunteer, has the same opportunity to contribute? How do you make sure everyone has a voice when those who come from a place of privilege are usually louder and in the majority? How do you teach maintainers and other community leaders to be more inclusive? How do you make respect part of your software lifecycle?
Mozilla and Kubernetes, both with numerous, widely distributed, thousands-strong open source communities are working toward diversity, inclusion, and accessibility at scale.
Today The New Stack talks about how these open source centers of gravity empower their contributor communities so that each member feels they have a voice at all stages of design and release.
Mozilla Joins Other OS Communities to Scale Accessibility
Mozilla is a community of open source communities — which includes the Firefox browser and Common Voice voice recognition — with about 4,000 volunteers in 121 countries.
Emma Irwin, as open source and communities strategist at Mozilla, was tasked with building an open source diversity and inclusion (D&I) strategy.
In 2017, research that spanned Mozilla’s communities and 204 other open source projects including Kubernetes, resulted in these 12 open source D&I recommendations:
- Provide organizational support to established identity groups.
- Develop inclusive community leadership models.
- Implement project-wide strategies for toxic behavior.
- Integrate D&I standards and best practices into product lifecycles.
- Build inclusivity into events.
- Break the language barrier.
- Generate diverse network capabilities.
- Experiment with accessible communication.
- Avoid exclusion by technical jargon.
- Mobilize community participation guidelines.
- Standardize incentives and recognition.
- Design inclusive systems that protect identity.
Since this time, many of these recommendations have been implemented. As part of project updates, Mozilla struck the word meritocracy from its governance page because “The notion of ‘meritocracy’ can often obscure bias and can help perpetuate a dominant culture. Meritocracy does not consider the reality that tech does not operate on a level playing field.”
What are small — and large — steps you can take to enact some of those 12 steps?
English: A Massive Barrier to Entry
Saying that gatekeeping is a huge open source problem, Irwin highlighted inclusive leadership as being critical for the cultivation of engaging and welcoming communities. Their research found that contributors who spoke English and who were most dominantly represented within a community— often men — both passively and assertively blocked the participation of other people.
English is the dominant language in most open source communities, which means, no matter how high their English level is, non-native English-speaking participants are often left behind. This offers disproportionate power to those who translate important information.
“I heard from one person [that] by the time they understand, things have moved on from there,” Irwin said.
Something as small as reminding leaders to provide transcripts of community discussions, which can then be translated, enables broader participation.
This also means that Mozilla goes out of their way to use text-based formats, which, while supporting translation, also allows people who are introverted or have limited internet bandwidth to respond individually and in groups.
Avoid that 1337 Speak and Just Explain the Role
Technical jargon can also restrict access. A Hewlett Packard internal report found that men apply for a job or promotion when they only meet only 60 percent of the qualifications, while women will only apply when they meet 100 percent of the qualifications. This statistic isn’t in isolation, but many surveys concur, as women and other underrepresented groups are systematically under-valued, underpaid, under-recognized and under-promoted.
Leaders need to acknowledge this disparity and be cognizant of excessively technical vocabulary within communities and in job descriptions, which make women less likely to step into a new open source project.
Irwin explained this is especially important in the Github repo: “It’s not a dumbing down, it’s just not a flexing. Some people flex their technical knowledge in conversation to elevate themselves.”
It’s also a good idea to highlight role descriptions as wish lists, and that candidates that meet some but not all of the criteria are still encouraged to apply.
Being clear about the expectations for a role up front is equally important.
Jaice Singer DuMars, who manages cloud native strategy for Google, said, “If you provide a solid scope of work or time expectations of what’s involved, you are more likely to have women apply to it. I first learned about this during a talk from Anita Sarma who has done tremendous work in the realm of open source inclusivity.”
Diverse representation in the release team is not by chance. We work VERY hard to invite people in, give documented roles (a known way to increase wider participation), provide shadow roles so people with impostor syndrome can overcome it. We still have a ways to go, and we will.
— Jaice (they/them) (@jaicesd) December 15, 2018
Acknowledge All Kinds of Contributions
Mozilla is also making leaders cognizant of acknowledging other contributions past the first pull request. OS communities tend to recognize code-based achievements, but those who answer questions in forums and who update a ReadMe in a technical environment also offer value to the overall project.
“The industry doesn’t seem to value non-technical contributions, and women tend to take more non-technical work on.” — Emma Irwin, Mozilla
In collaboration with the CHAOSS Project, Mozilla is working to standardize contribution measurement and recognition in order to better surface more achievements.
In her research, Irwin found open source communities tend to “recognize people who are good at surfacing their achievements — the loudest voice, the most productive people. Mothers and people in school and work are less likely to contribute. If we are recognizing people who have a lot of time, we are skewing recognition towards specific demographics.”
She went on to say that the loudest voice in the room is often the majority demographics who feels most comfortable with expressing themselves.
These aren’t huge prizes — like t-shirts or stuffed foxes, shout-outs on community calls, and coveted LinkedIn recommendations — but these shows of appreciation are incredible motivators for many OS volunteers.
So so many tech events give away T-shirts. Men’s T-shirts. This says you aren’t considering female attendees. I like this trend toward sock giveaways! #accessibility #monkigras pic.twitter.com/7XNKe1Y8Q7
— Jennifer Riggins💙💛 (@jkriggins) January 31, 2019
A code of conduct is the de facto guide most open source communities rely on as the rules of engagement. Almost all OS communities have one, but enforcement is often deeply lacking. Pointing out that bigger companies can move faster on such important issues, Irwin said that Mozilla collaborates openly with projects like Kubernetes and companies like Red Hat (now IBM) to scale codes of conduct enforcement with workflows that all-volunteer communities can easily replicate.
Why not just be nice to each other, you ask? If you’re someone that’s already underrepresented, and you’ve experienced toxic behavior in a community in the past, you’re going to look for different projects or stop contributing at all. People need to be confident that when they report abuses of codes of conduct, it will be addressed. Leaders have to be trained in how to not only enforce their codes, but also to provide consistent reminders.
Mozilla Open Source Support (MOSS) provides funding for open source projects. Before they apply, applicants are requested to answer a self-checklist on inclusion, which includes easy-to-accomplish low-hanging fruit like: Do you have a code of conduct? Have you reviewed an accessibility checklist? The goal is trying to make inclusion not feel like a big thing.
Going from One-to-One to Crowd Mentoring
Since open source communities are often so large and distributed, mentoring has arisen as an important way to help volunteers make the most of their contributions.
Paris Pittman, who manages the Kubernetes community strategy in her DevRel role at Google Cloud, calls the old-fashioned one-to-one mentoring usually random and ambiguous. In a lot of open source communities, you just fill out a form and someone matches you.
One-to-one mentoring simply doesn’t scale.
Pittman is trying to change that, building mentoring programs around different Kubernetes community personas and learning styles. One such way is the “mentors on demand” of the Meet Our Contributors YouTube channel, where Kubernetes volunteers just have to go online and ask questions via text, even anonymously if they want. It helps facilitate onboarding and updates at scale.
“It gives space to our contributors to get on a video call and share their path and experience. An ‘ask me anything’ kind of session as mentoring, getting legitimately the same things out of it as a mentoring.”
Pittman said there are usually about six mentors on each video call. In traditional mentoring, they would then mentor six other people. There are at least 100 views for each Meet Our Contributors session.
Pittman and her Kubernetes team are also working on a new concept of group mentoring — peer mentoring among the 26,000 contributors. They tested it out at last autumn’s KubeCon, where they did in-person mentoring of groups of at least three people.
“The mentors learned more from people in their mentoring pods.” Pittman explained that “Kubernetes is so large now that no one knows everything and [everyone] can learn in a small group together, not just one person’s experience.”
She continued that this format breaks up the ambiguity and potential toxicity of one-on-one pairings and creates more of a feeling of camaraderie. A one-way mentor-to-mentee relationship is often unclear what are the expectations and the timeframe.
“You have to have constant communication with mentors and mentees, and, in our busy schedules, you don’t necessarily prioritize and people just drop off. Also [there’s the] toxicity component with diversity — people just not knowing how to treat each other.”
Open source leadership has to be able to monitor for that toxic behavior and more open mentoring in small groups allows for more peer oversight. Overall, it just makes everyone feel more open and like they don’t have to talk to someone alone.
“As far as mentorship and diversity goes, the ways of yesterday aren’t today and therefore we have to look for different solutions, and different solutions mean work. We’re going to have to do the work to make progressive change. And if people are interested in that, come and find me.” — Paris Pittman, Kubernetes
She continued that one-on-one approaches are just because people don’t want to necessarily put in that work to think about it.
“If we’re trying to get a diverse set of contributors then we need to do things we haven’t done before and to explicitly ask people to participate. Traditional mentoring doesn’t fit those needs — it’s very easy to fill out a form and match up random people and hope for the best.”
Pittman continued that one-to-one mentoring works in co-located work environments where colleagues can naturally meet and seek out mentors, but not on widely distributed teams like is common in the open source world.
Google, along with the Cloud Native Computing Foundation, is also a big supporter of Outreachy, a paid internship program that supports diversity and inclusion in free and open source software. This is another way to support underrepresented communities through mentoring, as they are typically the ones least likely to be able to take on an unpaid role for experience.
Battling Imposter Syndrome with Shadowing
Shadow roles are also an important part of open source communities. This helps overcome Imposter Syndrome — the assumption that you aren’t qualified for a role, disbelief you don’t have value to add. In the Kubernetes community, shadow roles allow people to follow the primary for one release cycle before becoming that primary for the next cycle.
For the Kubernetes release team, a release leader is selected by the members of the release special interest group, and has to have been on two release teams before. This role is typically less of a technical role and more of a project manager, managing both the team and the delivery. By making sure the release team has a mix of technical and non-technical roles, Kubernetes can be more inclusive.
“For me personally, I try to identify people in the community who are great voices to be on a release team, and I specifically speak to them about the role and opportunity. In my experience, women and underrepresented individuals are more likely to volunteer when drawn into a conversation and asked to be included,” said Singer DuMars.
He says he always talks to people privately first before nominating them, especially for project-wide roles like the Steering Committee.
Kubernetes — which has a staggering Slack community alone of 60,000 people — has a very strong video and in-person culture, with just about all community meetings done over video.
But how do you know if someone is underrepresented or not in a mainly remote, distributed community? Singer DuMars isn’t searching for certain demographics, but rather he is thinking about whose voices aren’t being heard.
“I want to use my white male privilege and step back from the conversation and draw others in so they can take my place. And part of that is really learning what people’s skills and strengths are so they can step into roles that allow them to be really successful. I’m not doing my job unless I’m giving away my power.” — Jaice Singer DuMars, Kubernetes
Anything, where you have lots of volunteers, is complicated to manage and even harder to quantify, so small steps towards inclusion are key.
As Singer DuMars said, “Whoever shows up does the work. That can change rapidly,” so it’s up to everyone involved in an open source project to take steps to be more inclusive.
Want to join the movement to make open source community more inclusive? You can connect with everyone featured in this article plus many more working on inclusion in open source by signing up for this Google Group.
