Collectives and Identity
The free and open-source movements are a massive experiment in decentralizing the creation of software among a diverse collective of unique perspectives. This offers a potential glimpse for communities to form radical new ideas that upend the status quo.
There is a conversation in the room that only this people at this moment can have. Find it.
On paper, this may appear as the utopian egalitarian ideal capable of giving both equal voice and access throughout the development process. We bring our entire selves to these creation-oriented ecosystems and that can bring as much synergy as friction.
Indeed, many people get involved with free and open-source software seeking to contribute back to the community. However, prejudice – already an existential problem within computing – have only further distilled within these communities.
We must actively work towards equitable and accessible systems that value our perspectives yet hold us accountable to biases. This may require radical new ideas and implementations, but we can still learn the value of our voice within the crowd.
Who Contributes?
There are limitless reasons why people contribute to free and open communities, spreading the gamut from altruistic to narcissistic – and just looking to get a paycheck. The people who become integrated into these spaces are just as varied as the software projects themselves.
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
The ways in which a free and open-source project is organized can greatly impact their software. The inverse may also hold true – the software itself can play a role in the community that forms around it. These tensions are a dynamic process and every project responds to them differently.
Debian – the most popular community-supported Linux distributions – maintains a social contract that defines the expectations for affiliated volunteer developers. Each applicant must undergo a vetting process to better understand their technical skills, as well as their motivation and identity. With each influx of interest, the process has become more stringent. There are many reasons behind their contributions.
|
Diversity_3 |
Community Involvement Many volunteers are looking to give back to the community and find fulfillment through simply being involved with others. They may use the software everyday and want to support it.
This can take many forms: participating in hackathons; undertaking code reviews; updating documentation; or simply sharing the word.
|
|
School |
Continuing Education Some volunteers are seeking to learn a new skill or further develop one they already have. Established open-source projects often excel at onboarding new community members, providing valuable structure and mentorship.
|
| Paid |
Paid Work Not all people who contribute to open-source projects are by necessity unpaid volunteers. The largest contributions to projects like the Linux kernel are by paid employees working for the companies like IBM and Intel.
Similarly, corporate Linux distributions like Red Hat provide paid hours to developing the Kernel for their own software. It is not uncommon for contracted work to be incorporated into open source software.
|
| Interests |
Side Projects Some developers create their own software to solve a problem and end up sharing their solution freely, while others may seek fulfillment by creating something people like to use.
Solving puzzles with a community or fixing an irritating bug can scratch an itch. At the end of the day, it's about personal enrichment. |
| Cognition |
Personal Motivations Developers may be motivated by personal reasons stemming from emotional, political, social, interpersonal, economic or professional reasons.
Contributing to open-source projects can fulfill political agendas, build up a developer's portfolio, or create a reputation within the community. |
People are multifaceted and each volunteer may approach the project with overlapping motivations. Volunteers are free to resign at any time, for any reason – even without prior warning – through a simple public statement.
Diverse Perspectives
The free and open-source movements have grown steadily since the 1990s by offering solutions to everyday problems. A diverse community has emerged within people using the software, but the developers have remained rather homogenous: primarily young White men. This has become more concentrated within open-source communities.
Toxic behaviors have left underrepresented communities feeling unwanted and they are forced to leave instead of engage. While there is more visibility on the critical lack of diversity, more needs to be done to create inclusive spaces. We can all do our part creating an accepting community.
|
Diversity_2 |
Gender Even though programming was originally a femininized profession, there is a critical disparity when it comes to their representation within computing in general. This has only grown worse within the free and open-source projects. While researchers and journalists have employed differing methods for understanding this problem, they all reflect the same problem. Within the field of computing, approximately 22% of engineers identify as women. Women do not feel that they have equal opportunities for entering the field.
For open-source communities, this drops to estimates ranging from 1% to 3% when creating code. When taking into account non-software contributions, this may be upwards of 10%. The most recent 2021 report by the Linux Foundation suggests this has risen to 14% – still an incredibly small portion. Despite the recent increase of women in open-source, only 5% of projects have women as core developers. This is compared to over 30% of managers in computing being women. When code is pulled from an external developer's project, less than 5% of those developers are women. |
|
Diversity_2 |
Queer Identities There is a diverse spectrum of identities that we embody as we express ourselves. The diversity disparity in computing extends to people who identify as queer – or do not conform to societal expectations surrounding gender or sexuality.
An estimated 3% of the technology sector identify as queer within the tech sector, but this may not be a complete view. Identity can be personal and nearly half of employees do not feel comfortable being out with their identities at work. Overall, queer identities are underrepresented in technology.
Within the GitHub development community, there is more historical data available about how people's identities intersect with their contributions. Here, queer people have begun to find representation with 1% each identifying as transgender or non-binary as well as 7% considering themselves as queer.
The most recent report from the Linux Foundation suggests that this has been trending upwards. Through their survey, 74% of open-source contributors identify as heterosexual, 16% as queer and 10% choosing not to disclose.
|
| Diversity_2 |
Race and Ethnicity Similar to computing, there is a dire lack of racial diversity in the open-source communities. Black and Latine people are greatly underrepresented within software development. When it comes to management positions, the majority are filled by White men.
There is surprisingly little hard data available to better understand diversity. 16% of developers identify as a ethnic or national minority, compared to the national total of 34%. Latine, Black and Indigenous developers do not feel that they have equal opportunities to participate.
|
| Diversity_2 |
Age Developers within technology – and open-source software – are predominantly young. Nearly half of professional developers are between the ages of 25 — 34 years old. After the age of 40, job hunting within the field can be daunting.
Within large tech companies, the median age for workers is about 30 years old. When it comes to learning how to code, young adults from 18 — 24 years old make up nearly half of learners. |
| Diversity_2 |
Disability With the ability to work remotely on a software project, open-source software has helped some people contribute more regularly. Within open-source, surveys show 17% of contributors have a long-term physical, mental, intellectual, or sensory impairment. |
Barriers to Entry
Free and open-source software is used by the entire world in every field imaginable – from agriculture to sports. Open-source has become the default in many industries, but it is clear that the voices who contribute are not representative of the diverse audience using the software.
The Linux Foundation has addressed the importance of diverse and inclusive open-source communities. Debian has made efforts to address the problem including a paid mentorship program – but diversity may have actually decreased. Supporting a diverse community takes a multi-pronged: opportunities and healthy inclusive spaces.
Within the open-source community, there is a silent illusion that has grown pervasive. Since inception, it has presented itself as a meritocracy – where good code receives merit and you gain access to more paid opportunities. While hiring software developers, employers often consider open-source contributions as an important part of their portfolio.
The reality is that many people do not have have time, money or energy to perform free labor for open-source projects within the current economy. Those that can participate may unknowingly create a project hierarchy based on who can most frequently contribute – not who has the most to contribute.
Perceived – or enshrined – authority that can be leveraged though toxic behaviors. Linus Torvalds has a notably abrasive and demeaning style. Eric S. Raymond has made many inflammatory, outrageous and hurtful comments about people.
An unrewarding environment creates a digital fiefdom with uneven power and expectations – one project maintainer mandating it's direction. People who would otherwise have something to contribute choose not to participate with the project at all.
A meritocracy starts from the assumption that we all have the same opportunities and resources available to us. While a contributor's identity is not always obvious, this could explain why open-source projects are often so homogenous and lacking in diversity. Certain identities have an innate social privilege that can be wielded – either for or against others.
At times, the Internet can be an almost inhospitable place for women, people of color and queer identities. Women are twice as likely to experience sexual harassment online, while Black, Latine and Asian Americans have experienced targeted hate attacks. Despite historic contributions by figures like Alan Turing and Lynn Conway, queer people have faced discrimination and persecution in technology.
How would anyone expect folks who are in general harassed on the internet to suddenly trust an open source community to not behave the same way toward them, despite what its Code of Conduct document says?
— Nisha Kumar, Technical Lead
When grouping developers by their individual contributions, the percentage of women steadily declines as the number increases. This is because they are harassed at twice the rate of men, hindering their ability to become part of the community. For underrepresented communities, role models can be few and fleeting within technology.
When held to a higher standard than men, women can be left feeling alienated and have no choice other than leave. There is a general assumption that contributors are male and many women feel they must create fake accounts to be taken seriously.
We have been faced with a global pandemic, civil unrest and the rise of technofascism. People have become more emboldened to react negatively than to try and find common ground. Concerns about the open-source communities reputation for aggressive and unwelcoming behavior is well-founded.
Open-source contributers have expressed that, on the worst days, they "feel drained, unappreciated, and even abused". Almost a quarter of contributors have made the decision to leave a project in response to negative behaviors within the community.
While negative behavior might not be common, they are extremely visible to everyone else when they occur. Moderation within a public project can often be a difficult and thankless task. Every other contributor has witnessed toxic behavior within an open-source project's community.
When subjected to this treatment in their daily lives, there is no fulfillment to be found through integration into abrasive communities. Social biases undermine diversity by making underrepresented identities feel as if their contributions do not speak for themselves – that they are imposters within a predominantly young heterosexual white male dominated space.
I don't think I get the same level of respect for my experience that a man would get with the same number of years of experience."
— Nellie, a programmer
This is not surprising when we consider that open-source has long catered to abrasive personalities. Exclusionary and discriminatory language are a growing problem within technology that leaves people feeling excluded and unwelcome.
It can require a great deal of confidence to contribute to an community-created project – especially when your reception may be negative. When new and curious contributors are seeking a mentor, they may instead find they are treated as a burden.
Any time that I spend contributing to [open source communities] is time I could also be spending volunteering to advance LGBTQ equality, fighting against police brutality, and other issues that I care about, and that disproportionately affect underrepresented people—in fact, it's what makes us underrepresented in the first place.
— Perry Eising, Community Manager
Even though many developers have the ability to contribute on the clock, there are discernable discrepancies in the pay rates for women, people of color and queer people within technology. Women are more likely to be their family's primary earner on top of having domestic and family responsibilities.
The Value of Your Voice
There is arguably more talk today than ever about diversity, equity, and inclusion within the open source world. But is that talk translating to meaningful change? Are underrepresented groups actually participating in open source software development to a greater extent than they did in the past?
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.
opensource.com
For software to be considered open source, it must not discriminate against any people, groups, or fields of endeavor. In other words, open source software must be available and accessible to all users, which includes people living with disabilities. In many ways, the open source community and technologists focused on accessibility are a natural pairing: The more accessible the product, the greater number of users benefit, and input from a diverse group of users is necessary to build a product that is truly accessible.
"A distinguishing feature of open source software versus proprietary software is that open source software tends to be used by a diverse community of users with different priorities, needs, use cases," says Greg Myers, support engineer at GitLab. "I personally feel the more diverse and inclusive that community is, the better the end product is."
Engineers that draw from the insights of the open source community when developing their software benefit from a broader set of inputs than those that work with a proprietary codebase. In many ways, the standards that define open source software overlap with the process of accessibility in software development.
"Accessibility aims to do the same thing, right? We want to make sure that as we're building software, we're building it with a diverse set of folks that are going to use it, and might want or need to use the technology in different ways," says Brendan O’Leary, senior developer evangelist at GitLab.
Relative lack of open source activity from women and underrepresented minorities (URMs) seems surprising at first, but a closer look reveals some persistent problems regarding inclusion in open source communities. Inclusion is often used as a synonym for diversity; in fact, it is its own principle. To quote Meg Bolger, "Inclusion is about folks with different identities feeling and/or being valued, leveraged, and welcomed within a given setting (e.g., your team, workplace, or industry)." Some persistent, systemic barriers keep women and URMs from being included in open source communities. Without addressing and rectifying these systemic problems, diversity in open source won't improve.
For example, Linux creator Linus Torvalds famously took time off in 2018 to educate himself about empathy — a decision perhaps motivated by a sense within open source by that point in time that harsh and non-inclusive behavior was becoming increasingly intolerable.
Consider, too, efforts in 2017 to push Kubernetes to abandon its "master" terminology — a change that hasn't been fully implemented but that nonetheless points to efforts within the open source world starting around 2017 to take diversity and inclusion more seriously, even from a symbolic perspective.
The current inclusion of the historically disadvantaged might help wash some consciences without changing anything from the root. However, what is needed is a mental and structural paradigm shift. From there, it will be possible to build a more horizontal structure where decisions are made more inclusively and democratically.
And then there is the simple fact that the Linux Foundation in 2021 funded a detailed report to survey the state of diversity in open source. That's not something that the Linux Foundation, one of the most influential institutions within the open source world, had thought to do previously, despite regularly releasing studies focused on other aspects of the open source ecosy
Beyond the limited data about open source diversity today, there's also reason to believe that cultural changes within the open source world, and new initiatives designed to encourage greater diversity, are contributing to more inclusive open source communities.
That is why many open source initiatives, companies and foundations are actively working to attract more female talent and other underrepresented groups to make the open source environment a place for everyone.
The answer seems to be a tentative "yes" — although it's hard to say for sure, given the limited scope and inconsistent nature of the data available about diversity, equity, and inclusion in open source as of 2022.
In general, there has been more discussion within open source communities of the diversity issue over the past several years. And while it may be tempting to chalk that up to the broader social justice conversation that has taken place around the world over the past couple of years, the focus on diversity and inclusion in open source seems to predate the latter shift (although it may have been amplified by it).
https://biancatrink.github.io/
- Creating clear guidelines for behavior, such as a code of conduct, is one important way to address this issue. Women in particular were more likely to contribute to projects that have such codes, the survey found. Nadia Eghbal, who works for GitHub’s open source team, says that community leaders should make it a point to call out bad behavior when they see it, to let people know that’s not normal or acceptable behavior. Giving people the tools to block or hide problem users instead of having to wait for moderators to step in also helps.
- Create and enforce a clear code of conduct
- 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. -
Prioritize your project's documentation
A 2019 Stack Overflow study found that about 41% of developers have less than five years of experience. Between these new technologists and current emphasis on STEM education, there are lots of opportunities to welcome new open source contributors. In order to do so, project maintainers must lower barriers to entry—and clear, concise documentation is the first step.
- 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.
- Visibility: Questioned on whether they believe that their jobs are less visible or relevant because they are women, they mostly agree that they have not felt that. Nor have they had to show more effort to have their work considered or valued, although most accessed open source through a mentoring program for women or underrepresented groups.
- Opportunities: There is a diversity of opinions on whether they believe women have less opportunity than men in open source. The general opinion is that there are equal opportunities. They talk about having even more opportunities if you are a woman since there is less competition and many specific programs dedicated to women and underrepresented groups.
- Inclusiveness: In open source communities, inclusive and respectful language appears to be pretty well established. In some specific cases, the interviewees point out that it is still a work in process, but that it is something they have in mind, and initiatives and colleagues seem to be working on it.
- Awareness: When asked if they are aware of programs and policies to include and encourage the participation of underrepresented groups in their current company or project, the vast majority mention mentoring programs and a code of conduct.
- The importance of role models is essential. If women reach positions of power, they will show girls it is possible. Many mentoring programs use positive discrimination toward underrepresented groups, such as women, which is great and fair. Nevertheless, we will have more women at the mountain’s base. We don’t know whether those girls will believe they can glimpse the landscape from the top without other women pulling them up.
- 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. - 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. -
Reward contributions beyond code
In her time working on open
- 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. - Mentor new talent to grow and lead the project
- Regardless of your own project's governance model, you must include a way to train key contributors to assume leadership roles. This achieves three key goals:
Helping new contributors learn how they can grow
Rewarding contributors who own key aspects of the project
Preventing maintainer burnout - 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. - 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. - 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. - 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).
-
Stop saying you're a meritocracy
The first step to a more inclusive open source project involves understanding the meritocracy myth: The more you believe in meritocracy, the more biased your project is likely to be
-
Create learning opportunities often. Find ways to help people learn what you do and how you do it. Don't just wait for formal internship or mentorship programs, but take advantage of those if you can. Consider recording videos, holding AMAs, participating in events, etc. Be open to communicating with people informally in order to build relationships and trust so that you can help develop those with potential. Cast your net wide and you'll probably find those gem contributors who are ready to step in to help bring your project to a whole new level.
-
Be a connector. Try to have a mental map of prominent contributors in your community and their strengths. Share the mentorship by introducing newcomers to several people. Burnout is real on the mentor side and you want to make sure that there are other people your mentee can reach if you need to take a break or just get busy.
-
Make sure that there's a chat tool specifically for community interactions. In order to build trust, people need private spaces. Chat facilitates conversations and collaboration, and also allows people to message you directly. To avoid burnout, you may want to have a chat tool available just for your community / work conversations and a chat tool just for your personal life. That way, you can turn off all notifications on one tool if you need a break, or just simply have that mental separation thanks to differences in UX.
-
Connect through events. Events provide a powerful opportunity for you to connect with potential mentees. At these events, try to plan fun activities that are designed to help people connect informally. This may mean having a people-bingo where people have to ask each other questions to enter a raffle, or it could be a city tour, or a game night. Fun activities throughout the year can facilitate authentic relationships, which can also help people overcome fear of contribution.
-
Commit to continuous improvement
The work of inclusion is never done: It's ongoing. As your project grows, you will find new gaps to fill, questions to document, and additions to your Code of Conduct. As your community becomes more inclusive, it might feel like you're finding more ways you've fallen short. Uncomfortable as this is, it's actually a good thing. It means you've done the hard work of committing to keep on getting better. And, if you've done the work of building an inclusive team, you won't do this work alone. Instead, you'll share the work with your community, giving everyone the chance to share their feedback.
"Insisting that code is self-documenting is a form of gatekeeping [and] an example of an unhealthy project culture," Corleissen says. "I think the devaluation often comes from developers who see a static generator stack and think, How hard can it be? One of my least favorite dismissive phrases: It's just a pile of Markdown. If only it were that easy! Documentation is code for an environment where no chipsets are identical; kernel defaults are hostile; RAM is variable; storage is subject to random external dependencies; and production regularly fails despite optimal conditions, or inversely, succeeds in spite of obvious CI failures."
Financial Support
Donations
Sponsorship
Non profit funds
Open Collective is a crowdfunding platform focused on grassroots groups. It enables organizations, communities, and projects to get a legal status and raise funding through subscription or one time payment. It's particularly favoured by open source projects.[1] It currently hosts funding for thousands of open-source communities.[2]
https://www.spi-inc.org/donations/
https://en.m.wikipedia.org/wiki/Software_in_the_Public_Interest
Software in the Public Interest, Inc. (SPI) is a US 501(c)(3) non-profit organization domiciled in New York State formed to help other organizations create and distribute free open-source software and open-source hardware. Anyone is eligible to apply for membership, and contributing membership is available to those who participate in the free software community.
https://www.pledge.to/women-in-linux-4579
Community Support
Documentation
Feedback
Finding forums, chat apps, websites
Forums and mailing lists
Polls and feedback
Emergent strategy
Irc chatroom
I offer, from this defensive and sacred place, a protocol for those who are most comfortable approaching movements from a place of critique, AKA, haters.
1. Ask if this (movement, formation, message) is meant for you, if this serves you.
2. If yes, get involved! Get into an experiment or two, feel how messy it is to unlearn supremacy and repurpose your life for liberation. Critique as a participant who is shaping the work. Be willing to do whatever task is required of you, whatever you are capable of, feed people, spread the word, write pieces, make art, listen, take action, etc. Be able to say: ‘“T invest my energy in what I want to see grow. I belong to efforts I deeply believe in and help shape those.”
3. Ifno, divest your energy and attention. Pointing out the flaws of something still requires pointing at it, drawing attention to it, and ultimately growing it. Over the years I have found that when a group isn’t serving the people, it doesn’t actually last that long, and it rarely needs a big takedown—things just sunset, disappear, fade away, absorb into formations that are more effective. If it helps you feel better, look in the mirror and declare: “There are so many formations I am not a part of—my non-participation is all I need to say. When I do offer critique, itis froma space of relationship, partnership, and advancing a solution.”
4. And finally, 1f you don’t want to invest growth energy in anything, just be quiet. If you are not going to help birth or raise the child, then shhhhh. You aren’t required to have or even work towards the solution, but if you know a change is needed and your first instinct when you see people trying to figure out how to change and transform is to poop on them, perhaps it is time you just hush your mouth.
Development Support
Feature requests
Pull requests
Contributions