Diversity and inclusion are vital to the future of open source communities . Projects grow and thrive – and perform better technically and economically – when contributors with diverse perspectives, experiences, and skill sets participate. Open source communities seek to be open; this means they want everyone in the community who wants to contribute to feel welcome to do so regardless of gender, gender identity, sexual orientation, disability, race, ethnicity, age, religion, class origin, regional origin, educational background, political affiliation, or economic status. Open source communities can apply best practices to their communities that promote inclusiveness and diversity. To address these critical issues takes the strength of the collective community. Together, we can increase awareness, and subsequently address the representation gap—to benefit us all.
This guide outlines why and how to build a diverse and inclusive community of individual contributors and project leadership. You’ll learn how to frame a project for inclusiveness; how to set goals and measure progress; how to protect your community from bad actors; and gain tactics for increasing diversity.
Diversity and inclusion are important
Diversity and Inclusion (D&I) align with the ethos of open source communities. Open source invites all people to benefit from and participate in the creation of code. But open source projects often don’t include many people, particularly women and underrepresented groups. This misaligns with “open-ness” and it makes open source communities less effective. Research shows that teams with diverse members and those that are more inclusive, perform better, innovate more, and produce more profitable outcomes.
A 2017 McKinsey & Company report found that companies in the top quartile for gender diversity on their executive teams were 15% more likely to deliver above-average profitability than those in the bottom quartile, while those with ethnic and cultural diversity were 33% more likely to outperform. The reverse is also true: “The penalty for not being diverse on both measures persists,” according to the report. Companies in the bottom quartile on both gender and ethnic diversity “are more likely to underperform their industry peers on profitability.” They underperformed by 29% in 2017, the McKinsey analysts found.
Evidence also points to greater levels of diversity leading to higher levels of innovation. “We wanted to know whether companies with policies encouraging the promotion and retention of a diverse workforce – in terms of gender, race and sexual orientation – also perform better at developing innovative products and services. The short answer is that they do,” said Richard Warr, co-author of a research report and head of the Department of Business Management in NC State’s Poole College of Management. “To be clear, we found that there is a causative link – it’s not just a correlation,” Warr says. “And the finding extends across a broad range of industry sectors.” These findings are consistent with a 2004 University of Michigan Study that revealed that groups of diverse problem solvers can outperform groups of high-ability problem solvers.
Despite the overwhelming evidence that diversity and inclusion deliver significant advantages, the representation of women and other under represented in the tech industry continues to lag. Research from the National Center for Women and Information Technology shows that women comprised only 26% of the computing workforce in 2018. According to a report by ComputerScience.org, “the percentage of women working in computer science-related professions has steadily declined since the 1990s, dropping from 35% to 25% in the last 15 years.” Yet, representation of women in the workforce at large is the exact opposite: women are 47% of today’s workforce, as compared to 38% in the 1970s. The problem is not confined to finding talent to recruit, but in retaining talent as well.
The unique challenges faced in open source communities
Women are underrepresented in the computing workforce (26% according to the 2018 study cited above) but the numbers are even more concerning in open source communities, where women account for approximately 10-11% of contributors (according to data from Bitergia). At first glance a diverse and inclusive culture would appear to be a natural fit for open source communities, but that is not the case—obstacles such as bias, stereotyping, bullying, online harassment, and turf protections continue to hold back the true potential of ‘open’. “One thing many respondents said drives them away from open source projects are negative interactions such as rudeness, name-calling, stereotyping, and—at the more extreme end of the spectrum—stalking and outright harassment. Open source has a reputation for being aggressive,” Frannie Zlotnick, the GitHub data scientist who led a 2017 research project on gender bias in pull request acceptances, told Wired.
Companies depend on open source software for their products and infrastructure. In 2017, the Linux Foundation reported that over 80 percent of the software used in any technology product or service was open source. Open source is vital to the technology industry, but are open source communities healthy? The open source industry is looking at ways to assess project health and stability. As an example, the CHAOSS Project, announced by the Linux Foundation in September 2017, establishes standard, implementation-agnostic metrics to gauge the overall health of open source communities. One of the key metrics they look at are Diversity and Inclusivity. They’re read the research; D&I is an essential part of a project’s overall health.
While the business case for diversity and inclusion in open source communities is strong, solving the challenges and building a more open culture of individual contributors, maintainers, and project leadership is undeniably challenging. Open source communities present unique challenges because of the way they are created, managed, and sustained over time.
Unlike creating a workforce, an open source community is not hired. A project simply invites the world. It doesn’t select, it accepts. In this unstructured and unplanned way, the community evolves over time. Unlike the workplace, open source communities do not have the same mechanisms to create shared culture. Community members are working with people who may be working for competitors, may reside in very dissimilar cultures, and may have little desire to work well together. Open source communities may lack a leadership mechanism to govern behavior and resolve conflicts. As Gil Yehuda, senior director of Open Source at Verizon Media explains, “Open source projects tend to reward technical skills more so than leadership or management skills. When conflicts come up in a project, the project leaders might not know how to resolve an on-line conflict effectively.” Nithya Ruff, senior director, Open Source Practice at Comcast and a member of the Board of Directors at The Linux Foundation, agrees, “So it is unfair to expect them to become great leaders. In some cases, it may be a matter of pairing them with knowledge and best practices. In other cases it might amount to making sure that the project has both a technical leader and a community leader who’s able to bring those types of skill sets to the project. We need to bring issues and options out in discussions so that we enable maintainers to do the right thing.”
In an open source community, interactions often occur electronically, and usually in English, through mediums such as text messages on GitHub issues, Slack conversations and email threads, or in person at technology conferences. Underrepresented individuals may face a language barrier, feel insecure interacting in a non-native language, miss out on culturally informed idioms, have an unreliable internet connection, lack the resources to travel to open source conferences, and as a result, miss these opportunities to communicate and connect with other community members in the same way that those with greater access do. On the other side, people already participating in these communities may not perceive this communication inclusivity issue, and even more enforcing undesired situations with the use of jargon or subjective references, and new members may feel uncomfortable publicly asking for a clarification or specific meanings.
This lower representation in technology overall points to a shortage of talent overall, and in turn, to a limitation in attracting new contributors into open source communities. Talent shortages slow innovation and up the ante between open source communities competing for the available talent. It also hamstrings corporate contributors who are desperately seeking to add open source talent to their own rosters too.
According to a Linux Foundation’s Open Source Jobs Report, “87% of hiring managers report difficulty finding open source talent, and nearly half (48%) report their organizations have begun to support open source projects with code or other resources for the explicit reason of recruiting individuals with those software skills.”
Open source communities come under risk if the pool of contributors and maintainers is not maintained at healthy levels which can lead to open source burnout.
“I’m concerned about the fact that a lot of our projects are going to be very under-resourced. Many projects that a lot of us care about have one or two developers only, and a lot of us are becoming older and gray haired,” said Nithya Ruff, senior director, Open Source Practice at Comcast and a member of the Board of Directors at The Linux Foundation. “As we age, I’m concerned that, in our passing on the knowledge or expanding the contributor community and key projects such that we can sustain those projects, and the only way we can change that is if we open the doors and we do apprenticeships and mentorships and we actually pass the knowledge on and teach people and not just stay with, ‘Ah, it’s me, and it’ll die when I leave.’" But there’s more at stake than talent pipelines, succession plans, and the success of open source communities. “The other concern is as newer and newer industries get involved in additional transformation and start using open source, it’s as much about scaling and welcoming new industries into open source,” says Ruff. “Open source needs to evolve and change and embrace new industries and new people into this and be able to codify and share the culture with them and not just stay static.”
The following tips and guidelines are aimed to help increase the levels of diversity and inclusion within open source communities, with the recognition that each community’s culture is unique. We recognize this is a shared journey, and additional input is always welcomed.
In summary, the challenges in open source communities are:
Rude and unwelcoming behavior in projects drive away contributors
Open source communities have fewer tools for changing culture than organizations
English as a primary language can be a barrier to non-native speakers
Travel to conferences and face-to-face meetings may be unavailable to economically disadvantaged people
Diversity disparity in technology overall limits the pool of diverse contributors to open source communities
The culture that shaped initial open source community efforts is changing, including the value seen in the freedom that open source licenses provide
Using a Data-driven Approach
As management consultant Peter Drucker put it: “If you can’t measure it, you can’t improve it.” Metrics provide us with insights and best practices to help us succeed—and adjust where needed. This is true in diversity and inclusion efforts as well. Data can help guide us as we strive to increase the levels of diversity and inclusion within our open source communities.
You may want to start by determining specific community D&I goals from the outset and then measuring your community’s progress against those goals.
For tips and best practices, the CHAOSS Project’s Diversity & Inclusion Working Group, a group strongly rooted in Mozilla research is a great starting point. This group aims at bringing together experiences with measuring diversity and inclusion consistently across open source communities , as was done in the OpenStack Gender Diversity Report, and advancing best practices. The group has compiled dimensions of diversity and inclusion that can be used across seven focus areas of metrics, and uses a goal-question-metric approach to guide the development of metrics. The diversity and inclusion focus areas include:
Event Diversity: How well are events set up to include diverse people?
Contributions: What is the diversity of the contributions within a community, and how are these different contributions valued?
Communication Inclusivity: How diverse and inclusive is the communication among existing and potential contributors?
Recognition of Good Work: How is ‘good work’ recognized and rewarded in a way that is inclusive?
Leadership: Is leadership appropriately designed for inclusion, and how well is the group functioning?
Governance: How well are components of governance setup to enforce standards for inclusion?
Project and Community: How well are interfaces for community engagement, like project repositories and community design, setup for diverse people, perspectives and goals?
You can also look to other open source communities for inspiration.
“People across the TODO group membership are doing some really amazing things in terms of how they demonstrate support for inclusion in their projects as well as in their Open Source Program Offices (OSPOs) and in how they interact with the community,” said Nithya Ruff. “Perhaps capturing those best practices across the communities and aggregating and curating may be a good approach to take. One example is diversity scholarship sponsorships. A lot of us build healthy objectives into our own projects and sponsor events that are around diversity, so that’s one approach that would be good to take.”
Some good examples of diversity data reports exist and you can use those as templates for what data to look for and measure. You might want to start reviewing those listed on Open Diversity Data.
Beware of relying on “vanity metrics” that can make a community appear healthier than it really is. Vanity metrics skew results most often by measuring a less diverse group with another group that is more diverse to artificially inflate diversity numbers of the first group. An example in the corporate world would be to measure diversity by the numbers in the entire engineering department, which contains engineers and administrative assistants, rather than measuring diversity solely within the engineering job title.
To help avoid accidental vanity measurements and get the true measure of progress, consider the following guidelines listed on the ProjectInclude.org website.
Inclusion: Retaining Diverse Contributors
While diversity focuses on bringing underrepresented people into a community, inclusion is about making people feel welcome and supported within that community. Building inclusive communities is a good first step to ensure that all contributors can participate to their fullest potential within a community. Without an inclusive community, you risk diverse contributors not participating for long, and leaving your community for others that are more welcoming and appreciative of their contributions.
Possible solutions all stem from one goal succinctly stated by the Node.js Inclusivity Working Group in the code of conduct: “Increasing inclusivity means making the project a safe and friendly place for people from diverse backgrounds.”
The most successful approaches to making the community safe and friendly are sustained efforts. Approaches initiated and maintained consistently work more effectively than sporadic efforts with little follow-through. It is also important to guard against waning commitment after the initial rush of enthusiasm.
The important thing—whether in beginning to build an inclusive community or in improving one—is that the intent be obviously authentic and sincere rather than begrudging and shallow. While the goal is to build-in inclusiveness to the degree that it becomes an ingrained norm, this does not happen by accident. It takes substantial effort to build a community where all feel secure and openness is ubiquitous.
Here are recommendations to build and maintain inclusiveness:
Make it easy to contribute. Some great starting points for newcomers include documentation and tutorials—they help bring newcomers up to speed quickly and participate in a way that fits more smoothly with the group. Small, defined tasks both clarify project needs and broaden the number of people contributing to filling those needs. These tasks could be marked as “good-first-issue” for discoverability and more experienced community members should be prepared to leave the tasks open while being ready to mentor anyone who attempts them.
Recognize all contributions. While code is the center of any community, it’s not the only necessary task. “You can attract a more diverse set of perspectives and opinions when you count contributions that are not just code,” says Guy Martin, director at Open@ADSK (Autodesk). “When you count answering questions, when you count contributing documentation, when you count people who are working on outreach, people working on design and technical writing for the documentation—these are ways to widen the scope of what you’re looking at in terms of what’s a contribution.” The challenge is recognizing contributions that are not logged in collaboration tools (e.g., code repositories, mailing lists, forums) such as community management, event organizing, marketing, and outreach.
Create an accepting culture. While it is important to have common goals in the community, conformity in thinking is the antithesis of creativity and innovation. But, speaking out and offering new ideas can be nerve-wracking for anyone. You can create a welcoming culture where new ideas and new ways of thinking or doing things is accepted, whether it is coming from an established community member or a newcomer, using these principles:
Welcome newcomers. Make a point for community leaders and members to reach out and welcome newcomers as soon as they arrive.
Set expectations. Make it known how members are expected to receive and treat newcomers. Also set expectations on accepting more contributions and ideas from existing members who may have previously been discouraged from participating.
Don’t accept bad behavior and speak out when it happens. Make bullying, name calling, stereotyping, humiliation and other negative behavior taboo in the community. When these behaviors are unwelcome, individuals will have to communicate with more thought and sensitivity. And really, it’s just asking everyone to act civilly as they would anywhere else. Modeling tactful behavior in calling out bad behaviors also helps resolve issues.
Listen. Accepting begins with listening and so does issue resolution. Sometimes misunderstandings happen, especially where language and cultural differences exist. It’s important to sort these out before anyone reacts to anything. Active listening also means listen to everyone with an open mind. Don’t discount ideas or complaints – or accept excuses – out of hand. Look into issues and search for solutions. Then look again for ways to ensure the environment isn’t fostering such behaviors elsewhere in the community.
Be kind. Even old timers in the community will feel more relaxed and respected when kindness prevails. Newcomers will feel even more so. However, inclusiveness is more than just good manners. People can still be mistreated without voices being raised or threats made directly. You can combat this with sustained and expressed emphasis on kindness and professional courtesies.
Adopt a code of conduct and enforce it. In reality, bad behavior does happen in open source communities, whether or not it is intentional. Situations can get heated and communications may fall short of professional standards. Small acts of misconduct can easily escalate in an online community and harm project participants or the project itself. A Code of Conduct (CoC) is a social contract that encourages good behavior and discourages bad behavior in a community. A CoC helps address these issues and how they are to be resolved. It isn’t always easy to get all members of a community to accept a CoC, but it’s almost impossible to take steps to make and maintain a healthy, diverse and inclusive community without a CoC that can be, and is, enforced. Here is a good template to use, along with a great blog describing an example of an enforcement workflow.
A CoC addresses these types of issues:
when people disagree about a very contentious issue
when someone checks in code that breaks an important feature
when people join a project midstream and lack context about an old issue
when people are unclear in their communication style
when language and culture cause people to misunderstand
when someone feels the need to leave the community
when insults, threatening words or unwanted sexual attention occurs
“Some people think the Code of Conduct is there to weed out people or to police online behaviors,” says Gil Yehuda, senior director of Open Source at Verizon Media. “I think Codes of Conduct are more method for reminding all people to act with respect, even when things are stressing the community. A project leader can point to the code before something unravels into a fight, and that’s better than waiting for a complaint to be issued.”
It’s also wise to have an escalation path, or workflow, in place beforehand so that you’re prepared to enforce the Code of Conduct. Additionally, being clear on who is involved in decisions on that pathway will save time, and reduce complexity. With an escalation path and decision-making framework in place, problems can be addressed quickly and uniformly without generating disruptive chaos. “We can’t prevent harassment or abuse from happening, but we can enforce the consequences and protect the community from a downward spiral,” says Gil Yehuda. “A prepared workflow means we can react quickly when there’s a report. We’ll then run a review process offline, and report back to the community indicating there was an issue, and that we request that the issue is not discussed on the community forum,” Yehuda explained.
5. Consider ways to make your project more accessible. Focus on enabling internationalization within your projects. Specifically, take steps to break the language barrier, which will improve D&I contributions. Make all your documentation, tools, and official communication channels fully accessible to people with disabilities. The effect on your community will be very similar to breaking the language barrier. Improving the contributing experience for the most difficult cases improves the experience for everyone. A few ‘small start’ suggestions may include providing transcriptions and/or subtitles if you use YouTube, translating documentation into multiple languages, and live streaming your events. To put focus on these inclusion issues and formalize their status, a community may adopt a tag for inclusion bugs.
Attracting Diverse Contributors
When you’re ready to turn your attention to recruiting diverse contributors into your open source community, here are some guidelines to get you started.
1. Set goals and measure against them. You have to know what you’re aiming for if you’re ever going to hit the target. Name your goals and put tracking and metrics in place so you can manage your progress. As noted earlier, the CHAOSS Project’s Diversity & Inclusion Working Group can be a useful resource.
2. Include goals for diversity in project documentation. But don’t stop there. Communicate goals and actions to the community and ask them to assist.
3. Create a working group to proactively broaden the project’s appeal. A good example of such a group is The Node.js Inclusivity Working Group, which “exists to improve inclusivity and diversity in the Node.js project and surrounding community.” Another great example is the OpenStack Diversity Working Group.
4. Set diversity and inclusion goals/initiatives for events. Work your networks to identify and invite individuals to your event as speakers and panelists who fit your diversity goals. Recruit advisors from diverse backgrounds to help you communicate in a way that speaks to the people you have the hardest time attracting to your event. Communicate diversity and inclusion expectations from the first call for participation to the closing remarks at the event. Check out this 30-minute presentation by Christopher Neugebauer, Josh Simmons, Sam Kitajima-Kimbrel as an inspiration to running an inclusion-first event.
5. Connect with other community managers to share best practices/ ideas. The bigger open source community is your community too. Reach out to other community managers to learn what they’ve done that has worked, and to share your own ideas and experiences in D&I.
6. Be proactive about reaching outside of your network. You might consider supporting existing efforts or creating new groups outside your network that people from other networks can join in too.
7. Request that project leadership attend diversity training. Diversity training is different than sensitivity training. Sensitivity training is centered on awareness of one’s own prejudices and the sensitivity of others. Diversity and inclusion training “focuses on providing the knowledge, skills, and tools for working with diverse teams to enhance performance and impact the bottom line. This type of training is a key component of a diversity and inclusion plan,"according to K. Parks Consulting. This type of training will better equip you for the quest ahead. For example, the CNCF requires all of its community event speakers to attend inclusive speaker orientation training.
Other Recommendations
Research and information abounds to spark ideas and guide your progress. And you are not alone in this quest—many others are working on improving their communities too and are open to sharing and exchanging ideas. Further, the number of established programs you can join and support are growing every day. The fruits of those efforts will benefit the open source community at large, as well as your community. Here are a few other programs and steps that you might want to consider:
Participate in internship programs to grow diversity, such as Summer of Code andOutreachy or run your own, e.g., through CommunityBridge.
Provide transparency reports around D&I. The “Gender Diversity in the OpenStack Community” report is one good example.
Offer travel and training scholarships for project related events. Many foundations offer diversity scholarships and travel programs, including the Linux Foundation, Cloud Native Computing Foundation and OpenStack Foundation.
Start proactively outreaching for diverse speakers. To get you started, here’s a list of female tech speakers and organizers on GitHub. Another connection to find women speakers is @CallbackWomen, a Twitter account for women who are tech speakers.
All of the above are the lessons learned and insights gained so far. No doubt there will be many more. Feel free to add your thoughts, ideas, lists and programs as well.
Acknowledgements
We would like to thank Amye Scaravada, Chris Aniszczyk, Daniel Izquierdo, Emma Irwin, Georg Link, Gil Yehuda, Leslie Hawthorn, Matt Germonprez, Nicole Huesman and Nithya Ruff for their contributions to this guide.