Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
The Linux Foundation’s Diversity, Equity, and Inclusion in Open Source report found that many survey respondents felt welcome, but that positive overall result concealed worse experiences for several underrepresented groups. Published in December 2021, the 64-page study drew on a global survey fielded in July 2021 and interviews with more than two dozen open source leaders and researchers. It is useful as a detailed historical baseline—not as a measure of open source in 2026.
What the report covers
The full title is Diversity, Equity, and Inclusion in Open Source: Exploring the challenges and opportunities to create equity and agency across open source ecosystems. Hilary Carter of the Linux Foundation and Jessica Groopman of Kaleido Insights authored the report; Jim Zemlin wrote the foreword. The Linux Foundation published it in December 2021. It is 64 pages long, carries a Creative Commons Attribution-NoDerivatives 4.0 International license, and is listed with DOI 10.70828/KEWR6778.
The research set out to describe representation, belonging, and inclusion across open source communities, and to identify practices that might lower participation barriers and improve community health. Its understanding of diversity extends beyond race and gender to include gender identity and expression, ethnicity, sexual orientation, age, social class, caste, language, physical and neurological ability, religion, national origin, political affiliation, and related attributes. That breadth reflects the report’s premise that open source is global and that a narrow set of Western categories will miss some barriers.
The work was conducted with support from AWS, the CHAOSS Community, Comcast, Fujitsu, GitHub, GitLab, Hitachi, Huawei, Intel, NEC, Panasonic, Red Hat, Renesas, and VMware. The Linux Foundation report page links to the report and companion materials.
How the research was conducted—and what that means
The survey was fielded in July 2021 and was available in ten languages in addition to English. It collected more than 2,000 complete responses; some reported figures use a sample of 2,291. The researchers also conducted more than two dozen qualitative interviews with open source leaders, DEI program leaders, OSPO personnel, and researchers. The full report describes an ecosystem-level view, not a census of everyone who contributes to open source.
That distinction matters when reading the percentages. The survey records respondents’ self-reported experiences and perceptions; it is not an external audit of incidents or project cultures. Feeling welcome is not the same measurement as demographic representation. Interview themes offer context, but do not by themselves establish how common an experience is across the entire ecosystem. The findings describe associations and reported differences, not proof that a particular identity or practice caused an outcome.
Some demographic and regional subgroups were small, making fine-grained comparisons less certain. The report should therefore be read as evidence about the people who responded and as a source of questions for communities—not as a statistically definitive profile of every project, contributor, or region.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The headline findings
The report’s top-line results combine encouraging perceptions with clear warning signs. Percentages below refer to survey respondents, not all open source contributors worldwide.
| Measure | Reported result | How to read it |
|---|---|---|
| Felt welcome in open source | 82% | A majority reported welcome; the remaining 18% should not be obscured by that average, especially given subgroup disparities. |
| Identity affected ability to reach contribution goals | 30% | Nearly one in three said some aspect of their identity affected their ability to achieve their goals. |
| Disagreed that people from different backgrounds had equal decision-making opportunities | 22% | A substantial minority questioned equal access to influence. |
| Experienced exclusionary behavior occasionally or frequently | 17% | Respondents reported exclusion in community participation. |
| Experienced stereotyping based on perceived demographic characteristics | 36% | Stereotyping was more commonly reported than some severe forms of misconduct. |
| Paid for open source contributions | 14% | Most respondents did not report being paid for their contributions. |
| Agreed clear paths to leadership or maintainer roles existed | 37% | Clear advancement routes were not the experience of most respondents. |
| Students whose curriculum included open source | 16% | Formal education was an uncommon route into open source for student respondents. |
| Trusted codes of conduct to be enforced | 70% | Most trusted enforcement, but the report also found meaningful uncertainty and doubt. |
| Felt they could have a positive impact on the world through open source | 89% | Respondents could see value in participation even alongside reported barriers. |
The report also found that 55% felt their opinions were valued by project leadership, while 10% disagreed. It reported that 30% were unsure that codes of conduct would be enforced or somewhat disagreed that they would be. The report states that 22% had participation occasionally or frequently related to a code-of-conduct issue. These figures measure different things—confidence in enforcement and experience of an issue—and should not be collapsed into one claim about whether codes work.
The average hides unequal experiences
The central finding is not simply that open source is welcoming or unwelcoming. Most respondents described a positive sense of welcome, while several underrepresented groups reported more adverse experiences. The report found women, non-binary people, LGBQ+ respondents, and people with disabilities were twice as likely to have experienced threats of violence; transgender respondents were three times as likely. These are relative comparisons reported by the study, and small subgroup counts mean they should not be treated as precise estimates of risk for every community.
Routine exclusion can be less visible than a threat but still shape whether someone continues contributing. The report discusses dismissive responses, unanswered questions, rejected contributions, hostile language, stereotyping, interpersonal conflict, unsolicited sexual comments, stalking, threats, and doxxing. More extreme incidents were relatively rare in the overall sample, while ambiguous or everyday forms of exclusion were more common. Repeated non-response or contempt can make participation costly even when no single episode appears severe.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteThis is why the 82% welcome figure cannot stand alone as proof of equitable conditions. A project may be pleasant for most respondents while a smaller group encounters harassment, less influence, or barriers to advancement. Aggregate satisfaction and fairness across groups are different questions.
Barriers are built into how participation works
Time, unpaid work, and economic access
The report identifies time as the leading determinant of participation. Open source often assumes contributors can spend substantial hours learning a project, responding across time zones, attending meetings, networking, and developing professionally—sometimes outside paid employment. People with caregiving responsibilities, precarious work, limited free time, or employers that do not recognize open source work may face a higher cost of entry.
Only 14% of respondents said they were paid for their open source contributions. That figure is not a global accounting of open source labor, but it underscores that contribution opportunities are shaped by resources. Connectivity, geography, employment stability, event access, mentorship, and professional networks also affect who can participate consistently. A project may be technically open to anyone yet practically easier to access for contributors with employer support and reliable time and internet access.
Language and culture
English dominates much code, documentation, and community discussion. The report says 81% of respondents could read and write English well, while language remained a barrier for others. Fluency can be mistaken for technical competence, confidence, or credibility, disadvantaging people who know the technology but communicate in a second language. Offering a survey in multiple languages does not, by itself, solve the language demands of a project’s everyday work.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Onboarding and education
Only 16% of student respondents said open source was part of their curriculum. New contributors may have to discover the unwritten rules, tooling, review norms, and social expectations on their own. Clear contribution guides, beginner-friendly tasks, orientation, and mentorship can lower that burden, but only if project documentation stays current and experienced contributors have time to support newcomers.
Leadership pathways and governance
Only 37% agreed that clear processes existed for becoming a leader or maintainer. This points to a gap between being able to submit a patch and being able to shape a project’s direction. If authority is passed through informal networks, undocumented expectations, or discretionary invitations, contributors may not know what advancement requires—or may not receive equal opportunities to demonstrate readiness.
Governance also determines who makes decisions, how conflict is handled, and whether influential maintainers are accountable to the same standards as everyone else. A community can have diverse contributors but homogeneous leadership; openness at the contribution layer does not guarantee access to power.
Initiatives the report examines
Codes of conduct
The report treats a code of conduct as a baseline social contract: it sets expectations and signals that participant safety matters. But a published code is only a starting point. Communities need a credible reporting route, a clear process and authority for investigation, confidentiality protections, reasonable response expectations, and a way to understand decisions and appeals. If reports disappear into an opaque process—or rules are not applied to prominent maintainers—the document may deepen distrust rather than build it.
Inclusive naming
Changing exclusionary terminology in code, documentation, and repositories can make everyday project language more welcoming. The report places inclusive naming within broader cultural and structural change, not as a substitute for safety, accessibility, compensation, or fair leadership access.
Mentorship and sponsorship
Mentorship helps newcomers build technical and social knowledge; sponsorship goes further by actively advocating for someone and connecting them to opportunities. Both can improve access, but mentorship alone cannot repair opaque promotion rules, unpaid labor expectations, or hostile norms. Programs also need resourcing: otherwise, they can add unpaid work to maintainers who are already overburdened.
CHAOSS and measurement
The report discusses CHAOSS community health work as part of a shift from good intentions to observable outcomes. Measurement can help a project identify patterns in participation, retention, response times, and progression. It also brings privacy risks: demographic data should be collected only with a clear purpose, appropriate consent, careful aggregation, and safeguards against identifying or surveilling contributors.
Governance
Governance is where a project’s stated values meet its allocation of authority. Transparent decision records, understandable maintainer pathways, consistent conflict procedures, and accountability for leadership make participation more than the ability to file an issue or pull request. Without these, a community may be formally open while influence remains concentrated.
Recommended Free Tools
Practical steps for maintainers and OSPOs
The report’s recommendations—education, localization, measurement, ecosystem-wide responsibility, structural change, resources, proactive action, and better hospitality for newcomers—can be turned into practical review questions:
- Improve access: Are contribution instructions current and understandable? Are tools, events, and discussions accessible to people with different language and accessibility needs?
- Reduce time costs: Are meetings scheduled across time zones? Can important decisions be made asynchronously? Are moderation, documentation, translation, mentorship, and community operations funded?
- Make advancement legible: Is there a published path to maintainer or leadership roles? Are the criteria and decisions documented?
- Make safety actionable: Is there a private way to report problems? Who handles reports, how are conflicts of interest managed, and are influential contributors held to the same rules?
- Recognize the whole project: Are documentation, design, triage, translation, moderation, and project management treated as meaningful work alongside code?
- Measure carefully: Does the project look at retention, contributor progression, response times, and unresolved reports? Are any demographic measures voluntary, privacy-protecting, and appropriate to the project?
- Revisit and publish: Does the community share what it learned and what changed, rather than relying on a code of conduct or training session as proof of success?
Each intervention has trade-offs. Training can raise awareness but become performative if incentives and enforcement remain untouched. Translation expands reach but creates ongoing maintenance work. Targets can focus attention but encourage tokenism if retention and decision-making power are ignored. Metrics can expose disparities but must not become surveillance. Inclusive terminology matters, but cannot carry the weight of structural reform by itself.
What the report can—and cannot—tell us now
The 2021 study offers a snapshot of respondents’ experiences at that time. The available report materials do not establish that the survey has since been repeated with the same instrument, so its percentages should not be presented as the current state of open source in 2026. Nor does the study show whether its recommendations were implemented or whether conditions improved afterward. It is a baseline for comparison, not a present-day scorecard.
Readers can consult the results deck and infographic for companion presentations, and the open dataset for underlying data. Those materials do not remove the sampling limitations: conclusions still need to be framed around the survey respondents and the evidence collected in 2021.
The report’s enduring value is its insistence on asking more than whether a community is technically open or whether most people feel welcome. It directs attention to who has time and resources to contribute, whose communication is treated as credible, how safety rules are enforced, and who can become a decision-maker. To use it well, projects should treat its findings as a prompt to assess their own conditions—and gather fresh, privacy-conscious evidence before claiming that the ecosystem has changed.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
