Making open source more inclusive by eradicating problematic language

Open source has always been about differing voices coming together to share ideas, iterate, challenge the status quo, solve problems, and innovate quickly. That ethos is rooted in inclusion and the opportunity for everyone to meaningfully contribute, and open source technology is better because of the diverse perspectives and experiences that are represented in its communities. Red Hat is fortunate to be able to see the impact of this collaboration daily, and this is why our business has also always been rooted in these values.

Like so many others, Red Hatters have been coming together the last few weeks to talk about ongoing systemic injustice and racism. I’m personally thankful to Red Hat’s D+I communities for creating awareness and opportunities for Red Hatters to listen in order to learn, and I’m grateful that so many Red Hatters are taking those opportunities to seek understanding.

During a recent company meeting, Demetris Cheatham, Red Hat’s global lead for Diversity and Inclusion, reminded us that holding the space to listen and learn is about genuinely listening to one another with empathy and without debating or questioning someone else’s experience, and to recognize that there is a lot of hurt being felt by people around the world, including our Red Hat community. She said that “it will be the thousands of conversations that happen continuously throughout the year between peers and in teams that will really make the difference.” I commit to continuing to hold the space to listen, learn and have these important conversations.

Simultaneously, questions have resurfaced about problematic language in open source communities and code, and specifically the use of terminology like “master” and “slave”. This isn’t a new conversation - you can find instances where people have flagged this language’s use since the early 2000s. Despite pockets of change in a few communities throughout the years, broad progress has never occurred. There is no good reason for that. This includes within many of the open source communities Red Hat either sponsors or plays a significant role as well as within our own products and documentation. That must change.

If open source is truly meant to be inclusive and a place where anyone can participate, it must be welcoming to all. These are large challenges that large communities must respond to in order to drive systemic change. With that, Red Hat has committed to reviewing our own use of this problematic language and what we can do to eradicate it from our practices and vocabulary.

Red Hat is starting by standing up a team to audit our own work - our code, documentation and content - and identify potentially divisive language. We’d like to standardize on replacement terminology where we can. We’ll start making changes in documentation and content where problematic terminology is used conceptually (i.e. not referring to anything in the code). 

In code, some changes will take time because they will alter APIs and configurations used by running installations. We are committed to not breaking the user experience, so our engineering teams will assess the impact and create roadmaps with deprecation cycles. In open source it will require community efforts to make these changes, and in projects where Red Hat participates, we will advocate and contribute patches.

These efforts have already started. The Ansible community, for example, has started work to rename its "master" branch to "main" branch and phase out use of “whitelist” and “blacklist” in favor of “allowlist” and “denylist.” 

I’ve seen all sorts of arguments about why these changes are not needed. Some view these efforts as exercises in political correctness. Others argue that the intent behind the language was not malicious or that they do not find the use of these terms to be offensive or racially-charged because they are not being used to refer to people. I’d challenge you to remember what Demetris urged: listening to others with empathy is not about debating or questioning someone else’s experience.

If any person or groups of people feel unwelcome because of the language being used in a community, code or documentation, then the words should change. These changes will take time. They will require many conversations within communities and among vendors to fully enable. But those actions and conversations are worthwhile and we are committed to them. For open source to continue to be the best way to create better solutions faster, we must break down any barrier that could potentially inhibit participation. 

The conversations will continue at Red Hat about what we can do both individually and collectively to drive real change. And while working to eradicate problematic language from open source code and documentation is just one action, we hope you will join us in this and continue efforts to make open source more inclusive and welcoming to all.