Gender, diversity and inclusion in open source communities

In open source communities, the most important thing – apparently – are the contributions: the quantity and quality of work that is shared. This makes these communities, at a first glance, much more horizontal, since they are peer production spaces, where all are equal and have the same opportunities to contribute. By being able to view and study the source code, anyone with the required technical capabilities can make improvements. Those who gain the highest esteem (and power) in the community are those who have contributed the most and most significantly to the collective outcomes. The privileges and status earned are the result of their merits. And their merits are transparent because they can be seen in the amount of contributions made and accepted, in the number of editions done and in the ability to solve tasks. Tracking tools allow accurate monitoring of contributions.

For all this, open source communities take pride in their transparency and neutrality. Open source is agnostic regarding who is who in each new contribution. Recognition is granted based on the relevance and usefulness of the code or the content created. It seems something totally separate from the bodies that produce the code, and the social conditions that produce those bodies. Since these are mostly online communities, the body and its material conditions of existence seem to be diluted within the context of virtuality.

Open source is agnostic regarding who is who in each new contribution. Recognition is granted based on the relevance and usefulness of the code or the content created. It seems something totally separate from the bodies that produce the code, and the social conditions that produce those bodies.

But to simply accept these assumptions, without any sort of critical analysis, has two major problems:

First, open source hides social hierarchies. There is no equal participation for all in reality. Women, people of diverse gender, racialised people and people with disabilities do not have the same opportunities to participate, although there are no formal barriers that explicitly deny them participation. The result is that open source is biased and discriminatory, at least as much as other forms of technology and knowledge production. This disadvantages the participation and equal recognition of women and underrepresented groups.

Second, open source communities hide a lot of invisible labour. Especially non-code community work: data collection, project management, testing, design, technical writing, user support, and so on. Not counting all the emotional and affective work involved in community participation. As Catherine D'Ignazio and Lauren Klein explain in their work-in-progress book Data Feminism: “These forms of labour, both productive and reproductive, are of course essential to the success of the project, but are not currently rendered visible, nor could they ever be easily visualized, by a scheme that considers project contributions to consist of code alone.”

Of course, open source is not the same as proprietary code. When the code is open and available, and there is no need to request additional permissions, anyone can potentially participate, learn, contribute and benefit from open source. But even though open source participation is not explicitly forbidden for marginalised groups because of these conditions, there are other unperceived barriers that need to be analysed and eradicated.

In addition, for women and other marginalised groups, the transparency of code and data is essential to know the risks and biases that affect them disproportionately, and to have the opportunity to fix those problems and improve the code according to their specific needs.

Those are some main reasons why we are talking about gender, diversity and inclusion in open source communities. The code, although open, is not neutral with respect to who contributes and for what. What happens to our contributions when we reveal our gender or sexuality? How can a project in which a significant portion of the work is invisible and not counted really be “free” and open source? How can we introduce these concerns in commons-based peer production in general?

The code, although open, is not neutral with respect to who contributes and for what.

Next, we propose some tools and practices that can incorporate gender equality and social justice into open source projects. These tools can take the form of principles, policies, specific licences or complementary arrangements.

Principles

Before exploring tools for gender equality and inclusion in open source, we need a political framework that allows us to think and act intentionally. A starting point could be the Feminist Principles of the Internet, a set of 17 principles developed at the #ImagineaFeministInternet feminist meetings promoted by the APC Women's Rights Programme since 2014. Among these 17 principles, the first three, Access, Information and Usage, are closely related to the use of the internet to share open knowledge. The Economy and Open Source principles promote a feminist solidarity economy based on the commons. Additionally, among the principles related to Embodiment, the Consent principle is very relevant, related to the ability to decide how to share information online.

Another example is the Feminist Data Manifest-No, a feminist manifesto about ethics in personal data collection and use, which rejects the dehumanisation, discrimination and surveillance of harmful data regimes.

Licensing

Licences are the legal contracts behind open source projects. They are fundamental tools for collaboration, and are present in both free/libre software and open content projects. Free and open licences eliminate copyright restrictions that prevent collaboration, but they may also apply other restrictions to promote certain types of use and forms of collaboration. Copyleft licences are an example of this, since their “share alike” condition introduces a mandatory requirement: that derivative works must be shared in the same way. In recent years there have been licences called "copyfarleft" that take this tradition of introducing conditions for reuse oriented towards social justice principles. The Peer Production License developed by the P2P Foundation is an example of copyfarleft. Under this licence, commercial use of the licensed works is only allowed for actors in the social and cooperative economy, while actors in the capitalist economy cannot use these works for commercial purposes.

In 2019, the feminist hacklab la_bekka, from Madrid, created a fanzine that was licensed with a Feminist Peer Production licence. This is a “copyfair” type of licence derived from the Peer Production Licence. The new licence introduces the condition that people who reuse content must be organised under feminist principles. The legal terms of this new licence have not been developed yet, and its use did not extend beyond the aforementioned fanzine. However, it is interesting as an example to trigger the discussion: how do feminist principles and the building of the Commons relate? Could we think, for example, of licences that require recognition of reproductive work or even require compensation for that type of work? How could free and open collaboration be maintained under this assumption?

How do feminist principles and the building of the Commons relate?

These and other interesting challenges could arise in the field of licensing. However, to make open source collaboration more equal and inclusive, not all tools are reduced to copyright issues, as we will see below.

Terms and conditions

Online collaboration usually occurs on platforms (think of Wikipedia, GitHub, etc.) whose terms and conditions include aspects that go beyond copyright (and therefore, licensing). For example, the Wikimedia Foundation, as the entity responsible for the operations of Wikipedia and other collaboration platforms, has established terms of use to define how collaborators who want to contribute content on these platforms should behave.

In addition to the content licence, these terms and conditions include other responsibilities of collaborators, such as avoiding violent and harmful behaviour. They also include the mission of the Wikimedia Foundation, its role in the operation of the online services it hosts, as well as the privacy policy, among other aspects.

In this and other examples, we can see that open source collaboration is also framed in the terms and conditions of the platforms on which it takes place. These terms and conditions are not always that obscure legal text that we avoid reading, since we know that we are accepting a Faustian pact of personal data extraction and relinquishing our rights. Sometimes, on the contrary, they can contain valuable guidelines that organise the collaborative process, and can be a first step in establishing norms of participation and inclusion.

Open source collaboration is also framed in the terms and conditions of the platforms on which it takes place.

However, as the Wikimedia community has learned, terms and conditions are often insufficient. To address abusive behavior that undermines collaboration and diversity, more decisive steps are needed, such as the drafting of a community code of conduct, as we will see below.

Collaboration “mantras”

The writing of terms and conditions can be legally complex, and perhaps not feasible for all open source projects, especially those who are community driven and volunteer based. However, rules can be established and enforced by the community without requiring a team of lawyers. It is about establishing some collective norms that, in the manner of “mantras”, shape what culture of collaboration we want to build together.

In the Mozilla Open Leadership Training Series, we can find guidelines and examples on how to build an inclusive framework for open collaboration. We can start by writing a README file, and then add other documents, such as a Contributor Guidelines and a Code of Conduct, even adopting and adapting others already written. To deepen this type of agreement and give a more precise framework for collaboration, a code of practice can be established, which clarifies work routines, forms of leadership and decision-making methods. A good example can be found in the Information Maintenance initiative.

It is about establishing some collective norms that, in the manner of “mantras”, shape what culture of collaboration we want to build together.

These may not be legal texts, but they can help create a positive culture for contribution and collaboration on open source projects. If we warmly welcome all people who want to participate, if we explain the various ways in which they can contribute, define how it will work and clearly state what behaviours are expected and what behaviours are unacceptable in our community, we are establishing the basics for inclusive collaboration. These are key tools to open up the project to a greater diversity of participants and create a comfortable and safe space for everyone.

Documentation

In addition to making the source code of a project available, it is essential to provide adequate documentation so that other collaborators and users can see the sources and contribute to the project. Documentation is an aspect of openness and inclusion, because it makes projects replicable and reusable. Otherwise, only a group of initiates can drawn from these sources to create something new.

Furthermore, documentation is important for those who tend to be left on the sidelines and less recognised in open source projects. In her Survival Tips for Women in Tech guide, programmer Patricia Aas recommends: “Document all your work. It's hard to steal credit for public work.” This is a way to tackle the invisibility that women and other people from marginalised groups suffer by default. Writing a blog or a wiki, among other ways to make work in progress public and open, is a tool for recognition and visibility.

Documentation, in short, has a double advantage: it democratises the knowledge necessary for participation in an open source project, and makes those who participate more visible. That’s why it must be carefully practised in projects that are especially concerned with inclusion.

Documentation, in short, has a double advantage: it democratises the knowledge necessary for participation in an open source project, and makes those who participate more visible.

In summary

Despite being based on horizontal peer-to-peer collaboration, open source communities often hide social hierarchies and make the work of women and other marginalised groups invisible. Access to the source code and permission to reuse it are potentially inclusive elements, but they do not act by themselves to ensure inclusion and diversity. It is possible and necessary to intervene intentionally, using tools that can be moulded to be gender and diversity sensitive. Under feminist and social justice principles, a more fair and inclusive culture of collaboration can be fostered. There are several tools in which these principles can be embedded: open source licensing, terms and conditions of collaborative platforms, codes of conduct, guidelines for collaboration and documentation, among other aspects that encourage creative, free, open, diverse and socially just collaboration.

This article is a pre-print version further edited and translated from Fossatti, M. (2020). Gender, Diversity, and Inclusion in Open Source Communities_. XRDS, 26(4), 46-48. https://dl.acm.org/doi/10.1145/3398454