July 05, 2020
3 min read

Creating Inclusive Code for a Better Tomorrow

Photo by Clay Banks on Unsplash

Phil Karlton once said, “There are only two hard things in Computer Science: cache invalidation and naming things.” It’s not particularly hard to select a name; the hard part is choosing one that is clear and means the same thing to everyone reading.

Jonathan Marsh, an American working for WSO2, supports customers and prospects across the globe, and at times has witnessed subtle bias against international colleagues—impatience with unfamiliar accents or idioms, conflating Sri Lanka with India, making unfounded assumptions about technical competence based on country of origin, etc. While we patiently work to dispel these preconceptions with friendliness and demonstrated competence, we glimpse how damaging both subtle and aggressive forms of bias can be on the communities suffering beneath them.

The open-source ethos is one that promotes accessibility for all. This is hard to achieve when commonly used terminology in our code and documentation can turn away a segment of the potential community. In programming, naming is key to our perception of how software and hardware work, and much like the language we use in our everyday lives, it influences our comprehension of the machine world. For example, the names we use describe how objects communicate with one another and help to understand a particular codebase.

This means the words we use should be carefully considered.

Terms like master/slave, blacklist/whitelist, and black hat/white hat enforce the discriminatory narrative that “white”==”good” and “black”==”bad”; they reference unequal social constructs that are the result of a particular time period in our history. Associating positive connotations with “white” (like whitelisted) and negative undertones with “black” are not only profoundly offensive but also completely unnecessary. There are also many other relationships that can be used as more accurate metaphors.

We have decided to excise prejudicial terms and descriptions from the entire body of source code across our products and projects and substitute agreed-upon words to take their place.

Why?

At WSO2, we have always drawn strength from our diversity. Our work has always centered around our founder’s vision of making the world a better place through software. However, even the most well-intentioned technologies can become pointless if those that build them do not adopt the values of inclusivity and practice them every day. Current events are highlighting the need to confront biases built into our own technical field, such as the unquestioned adoption of industry terms that are inherently biased. We have an opportunity to, and are committed to, combat bias wherever it appears. Often, it’s hard to see your own biases and we rely on our community to help us; if you detect bias in our communications or operations, please bring it to our attention.

How?

Our product engineering leads recently led an internal project to find and replace offensive words in our infrastructure. Overall, the changes for what we could control took a short amount of time to enforce. We aim to update all our documentation with unbiased language by the end of July.

Here are some examples of our efforts.

While the tech industry has a lot of work to do in the movement for racial justice and equality, such as hiring and empowering those from underrepresented backgrounds and ethnic groups, there are pressing issues that can be addressed right now. This includes reflecting on and changing the insensitive terminology that is common throughout our industry.

We need to act collectively to abandon this practice. The numerous fights for racial equality throughout the years have shown us that small actions add up; that’s how bigger movements start and changes for the better take place after all. To paraphrase Ron Eglash’s concluding line in his essay ‘Broken Metaphor: The Master-Slave Analogy in Technical Literature’—we can (and should) do better.