If the tech industry has a diversity, equity and inclusion problem, then the open source world has a catastrophe on its hands. While women make up a still shameful 20 to 23% of the tech industry, women and other gender minorities make up only about 3 to 4% of OSS. While Africa represents 16% of the global population, it makes up just 2% of GitHub, the world’s largest open source repository. There are many other important DEI measurements to be made, but there’s still surprisingly little research being done.
As open source 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?”
This lack of diversity is unacceptable. Open source dominates at least 70% of enterprise stacks. It’s an essential tech skill, with open source contributions continuing to rise. Open source is even more important in the Cloud Native space which is built on open source projects, making Cloud Native experience a must-have for the highest paid roles in tech. Contributing to an open source community is also a fantastic way to network, gain core social skills, and give proof of code, all supporting your next gig.
The open source tech experience can be special because of its communities, but that’s where it’s really losing out by its lack of diversity. And if open source is building the future, then everyone must be represented in its creation.
Open source communities can be, by nature, unwelcoming
Some of this diversity problem is self-fulfilling due to the unique nature of open source. As Divya Mohan explores elsewhere in this WTF collection the vast majority of open source contributors are either volunteers or work for sponsoring organizations. Those in minoritized groups are more likely to bear the brunt of unpaid care work and don’t often have the extra time to donate. And Fortune has found that the world’s biggest companies, who are the frequent sponsors of high-profile OSS projects, are still lagging behind in diverse hires.
Also there’s an attraction to abscond your identity in an open source community, which may be falsely keeping some contributor demographics lower. This can be because you feel isolated as the only woman or person of color contributing to a project within a country.
Or it could be because you just want your code approved; a preliminary study suggests that the pull requests of women who hide their gender are more likely to be accepted than men or women who are open about it.
There’s also the staggering accounts of harassment from both victims and witnesses. The 2017 GitHub Open Source Survey, which remains the broadest examination of DEI in the space, covered a lot of negative behavior that deters contributions. Sexual harassment, stalking and/or doxxing is experienced by about 3% of contributors and witnessed by about 14%. Again, these are unacceptable levels that lead to contributors dropping out.
Dr. Vandana Singh's combination of anecdotal and empirical research has uncovered “hostile, discriminatory and predatory experiences of women and underrepresented minorities” in open source communities. She is a recent recipient of the Google Research Award for Inclusion Research and has dedicated her career to studying open source communities.
GitHub has found tooling to be the most effective way of addressing harassing behavior—namely reporting and blocking features—but that shouldn’t get maintainers and other community leaders off the hook. There are a lot of other ways to foster safer, more welcoming communities that can’t be automated.
And remember, an unwelcoming open source community doesn’t just interrupt people from voluntary contributions, it can block their success at their current and future jobs.
Enforced codes of conduct matter
One of the most significant trends over the last few years toward diversity and inclusion in both open source communities and in tech events in general is the widespread adoption of codes of conduct—which outline expected behavior in a community and consequences of not meeting those expectations. This is in part because in 2015 the Contributor Covenant became the de facto CoC for open source communities.
But even as this covenant reads: “Simply adopting [the] Contributor Covenant will not prevent conflict or toxicity in your community.” You have to enforce it. “A code of conduct without such enforcement sends a false signal that a community is welcoming and inclusive, which can have a disastrous impact on marginalized or otherwise vulnerable people.”
Singh’s research has found that women strongly consider open source codes of conduct before making their first contributions, specifically looking for mentions of diversity and how problems will be addressed. She’s found that the most successful codes are adapted to speak to the specific community and call out the specific kinds of diversity it is working to include—and how.
Open source leadership should come to expect that people are going to break the codes of conduct—otherwise you’re not being aspirational enough for your community. Some communities like the Cloud Native Computing Foundation automate responses to inappropriate language within Slack, while others leverage linters to keep them out of documentation. You can also set up Slackbots to remind folks about the code of conduct.
But when someone is a repeat offender or does something more egregious, She Code Africa’s open source program manager Zainab Daodu says you have to make an example of them. This can be through a public apology or even suspension from the community. And always respond publicly, secrecy builds apathy and a sense of insecurity.
Always remove offensive behavior from triggering someone else—but not without screenshotting receipts first.
And, as our Container Solutions colleague Carla Gaggini pointed out, it’s especially important that leadership is held up to the same standards. If a maintainer is caught breaking your code, they should be made an example of.
How to welcome anyone
Singh’s most recent research is aptly titled “Motivated and Capable but No Space for Error.” Unsurprisingly, all women she interviewed reported a lack of other women in their immediate open source environments.
One respondent said she is sick of being singled out as representing half the world population:
One thing I always hate is that they point me out all the time, ‘Oh, you’re a female. What’s your opinion?’ Like I’m some kind of a dinosaur in the room, and I have to have an opinion because I’m a woman. And I have to represent the multitude of women that are not in the room. No, I’m not representing them. They should be there with me. I think, again, almost equally, but because we are missing so much in numbers, we lack opportunities and presence, definitely.
This feeling of isolation is likely to be replicated across all underrepresented demographics. And "Only Black Developer Syndrome" is a real problem talked about all the time. As Coding Black Females founder Charlene Hunter said, “I shouldn’t have spent eight years of my life not meeting another Black woman who does coding and has the same skills as me.”
Safe spaces ranging from special interest groups (SIGs) to meetups and both private and public Slack channels can allow those both with technical and social interests to self-organize and feel less alone.
This can also have an added benefit that not only you’re offering support, but it helps you know profiles of those from underrepresented groups to highlight—with permission of course.
We all know that onboarding is essential for any tech retention. It could be doubly so in open source communities. Singh has found first experiences to be essential in determining whether women stick around to become active open source community participants. By pairing new contributors with warm and welcoming mentors, you automatically create a safe space to ask for help navigating the often complex communities—from where to start contributing to who to ask for help with what.
Diversity of thought and experience matters, too
Another bad habit that bleeds over from marketing in tech all the way into documentation and product is the use of the words “easy” and “simple.” As developer advocate Wesley Faulkner put it, “If a new learner has an issue with one of these ‘simple’ steps, they may give up and not continue because it’s only going to get harder, right? Removing that wording will help to not add additional pain and shame that comes with learning something new.”
It’s better to mark things as beginner—and guide them to beginner Slack channels—as well as to flag other levels. Often someone who is contributing to your open source project for the first time may have loads of experience in your language or domain and be ready to help you with a more advanced issue.
Another part of onboarding is that, in open source, it’s not just about getting to Hello, World. There are so many more opportunities to contribute that are as important and need as much recognition as coding. Make sure your leader boards aren’t just highlighting people with the most pull requests — quantity of code should not be the only gauge of quality of contribution.
Documentation is often poor or lacking in tech but the problem is notoriously bad in most open source software, because technical writing is a skill that is often under-appreciated by developers, who already have ever-expanding responsibilities. This is particularly ironic given that for an open source project you really want users and contributors to do as much self-service as possible. Documentation not only helps people learn about your code, it helps learn about your community and its purpose. It creates a written history of decisions made and creates a baseline knowledge for everyone. Doc writing should be a celebrated OSS contribution.
A win-win contribution that helps the community recruit and increases diversity is translation work. The tech industry overall persists diversity issues by putting English proficiency as an artificial barrier to entry.
Developer advocate Kat Cosgrove also recommends that you define a concept, tool or word the first time you use it—at length. “Explain not just what that thing is but why it’s so useful. I don’t have the experience you do; I need context and the why to understand,” she said.
All tides rise together. Like most open source diversity, equity and inclusion efforts, when you do something to welcome one group, you enrich the community experience for everyone. Helping one person be successful, helps everyone be successful.
Previous article
