Throughout his long career in tech, Blacks in Technology executive director Peter Beasley heard programmers use the terms “master” and “slave” to refer to development branches or databases many times.
“Did I, Peter Beasley, start a movement or make a big deal about it? No, I didn’t do that. But I personally tried not to use those words,” he said. “I would never use them.”
Did that make his job harder?
“I’m going to say yes,” he said. “Not the words themselves, but the fabric they’re a part of.”
A Black technologist could work, thrive, and even lead at an organization that uses those terms, Beasley said. But the presence of words like “whitelist,” “blacklist,” “master” and “slave” would serve as constant reminders — and reinforcers — of the racist structures that make a workplace less welcoming for Black people.
Many technologists like Beasley are fed up with both the words and the fabric they represent. In the wake of the most recent wave of #BlackLivesMatter protests against police violence and systemic racism, some notable companies and open-source projects announced the decommissioning of terms with offensive connotations.
“I personally tried not to use those words. I would never use them.”
Some of these efforts — like the decision by the Jenkins governance board to replace three terms — came from the top down. Others came from engineers themselves. Twitter developer Regynald Augustin, along with his colleague Kevin Oliver, successfully lobbied to replace a variety of terms, including “man hours,” “grandfathered,” “dummy value” and “sanity check.”
Linux, GitHub, Apple and Google Chrome and Go are among the other projects that recently announced terminology deprecations.
The problem of racist terminology in the workplace isn’t new. But the commitments from large companies and projects may signal shifting dynamics for developers, both in and outside the codebase.
How Much Do Words Matter?
Terminology changes have met mixed reactions.
Many replies to Augustin’s Twitter announcement were vitriolic. A note from Go developer Filippo Valsorda on the commit to replace “whitelist/blacklist” and “master/slave” acknowledges ongoing arguments about the changes:
“I’m not trying to have yet another debate,” Valsorda wrote. “It’s clear that there are people who are hurt by [the terms] and who are made to feel unwelcome by their use due not to technical reasons but to their historical and social context. That’s simply enough reason to replace them.”
Others, like writer and actor Kerry Coddett, criticized the broader pattern of name changes in response to #BlackLivesMatter.
“Y’all removing racist symbols when we’re asking to remove racist systems,” she tweeted. “We are not having the same conversation right now.”
But just because the impact of language changes isn’t immediately clear doesn’t mean those changes aren’t significant, Peta Hoyes said. Hoyes is COO and a partner at Tag1 Consulting, a firm that helps optimize websites built with the open-source Drupal framework.
“I agree wholeheartedly that we should address the issues, not just the words — but the words are still important because they have real effects,” she said.
She thought of tennis star Serena Williams, who in 2015 was named Sports Illustrated’s Sportsperson of the Year. The honor sparked a social media debate over which contender deserved the award more: Williams or American Pharoah, a Triple-Crown-winning horse.
The argument was absurd. But the dehumanizing language sports enthusiasts used to discuss Williams’ performance had seeded the racist debate long before it flared up, Hoyes said.
“As a Black woman who exists in that air, there are a lot of things I shove to the side because I don’t have that time in the day. I have to pick my battles.”
By themselves, words are symbols. But you can’t divorce words from their contexts, Hoyes said. If technology organizations are homogeneously white and male, that context may be lost on many. But as spaces become increasingly diverse, some language hits differently. Tech workers should take the time to listen to their peers and examine the historical and cultural contexts of the language they use, she added.
“This is the air we breathe, for all intents and purposes. When your diversity starts to reflect the actual population, people start to realize, ‘This air works for me, but it might not work for other people,’” Hoyes said. “As a Black woman who exists in that air, there are a lot of things I shove to the side because I don’t have that time in the day. I have to pick my battles.”
Hoyes said that Black employees, especially Black women, face constant decisions about whether or not to address racism in the workplace, weighing their time, energy and security against the severity of the incident. That’s what makes it especially important for white colleagues to think critically about language at work, as well as interactions, protocols and systems.
In that sense, terminology changes are indeed small — because they’re the tip of an iceberg.
How Do Terminology Changes Happen?
Some technical terminology changes are coming from project leadership; others happen when developers like Augustin push for new company-wide language.
But not all are the result of organized efforts. Some changes happen line by line, merge by merge.
For instance, Python officially deprecated “master/slave” from its codebase in 2018. But before that happened, community members were already chipping away at terms they found offensive.
In 2017, Python core developer Mariatta Wijaya found herself helping out with a GitHub bot that flagged pull requests from accounts that hadn’t signed the project’s Contributor License Agreement. Since some pull requests come from automated processes, they needed a way to exempt those requests and prevent them from being flagged — Wijaya was asked, via a GitHub issue, to create a “whitelist.”
“When I implemented the bot, I made a conscious decision,” Wijaya said. “I didn’t want to use the term whitelist.”
So, she did a Google search for alternatives and settled on “allowlist” instead.
When she implemented the feature, she didn’t call attention to the terminology swap. The developer who’d opened the issue accepted her contribution, and nothing more came of it.
“I don’t know if he noticed. I never asked him about it,” she said.
“When I implemented the bot, I made a conscious decision. I didn’t want to use the term whitelist.”
In that way, Wijaya changed the terminology in one project — quietly and unilaterally. For huge codebases such as Python, that approach to project-wide change would, admittedly, be slow going. But, particularly in open-source communities, more sweeping changes can lead to stronger blowback.
When a Python developer opened an issue the following year requesting that all instances of “master/slave” be replaced, that request was eventually accepted. But it also prompted ideological and personal attacks. The core developer involved with that change asked that Wijaya not share his name.
It harks back to a common critique of open-source communities: The anonymity, written messages and no-holds-barred technical debates enable abusive speech. That’s why the Contributor Convent, a document outlining the bounds of acceptable behavior in open source, exists. Many projects have adopted the Covenant. But for some people, both the Covenant and recent terminology changes are unwelcome signs of shifting demographics and the tightening of unlimited speech.
When discussions about terminology changes surfaced in the Linux community in early July, for example, some detractors directed death threats at Coraline Ehmke, the author of the Contributor Covenant, even though she wasn’t directly involved in the changes, Ehmke told Built In.
While the removal of terms like “master/slave” specifically targets anti-Black racism, these terminology changes are part of a larger effort to make open-source spaces more inclusive. In a 2017 GitHub survey of open-source contributors — the sole formal source for data on open-source participation — 16 percent of respondents identified as racial or ethnic minorities. Three percent identified as women. Those imbalances have led to a variety of programs, including internships and mentorship programs aimed at boosting participation from people in underrepresented groups.
Wijaya herself became a Python core developer after being mentored by the language’s creator, Guido Van Rossum. Her hope is that, by increasing access to mentors and removing barriers to entry, open-source communities will continue to diversify.
“It takes individuals [in the community] making an effort themselves,” she said. “But if the leadership sets an example, people at the bottom who admire the leaders start doing the same.”
Changes Are Announced — What Happens Next?
Alex Earl is a member of the Jenkins governance board, which helps guide the project and make important decisions.
After George Floyd’s death at the hands of police made national news, the board decided it was time to move forward with terminology changes they’d been considering for years, Earl said. They’d started the process of removing “slave” back in 2016, but since then, contributors had reached out with concerns about other terms — “master,” “whitelist” and “blacklist.”
They started a thread in Google groups to poll the community on the best replacement terms. Contributors spent two weeks throwing out suggestions.
“I encourage Jenkins contributors to participate in this effort,” one wrote. “It is not something we could change in a minute, but we could do a gradual clean-up and improve the overall documentation while doing so.”
“I personally think without the ‘slave’ context, ‘master’ is pretty accurate,” another weighed in. “To be absolutely honest, if it has more syllables than the current, people are super likely to stick with the existing wording.”
Next, the governance board will collect the proposed replacement terms and list them in an online poll for the community to rank. The board will use those rankings to determine the final replacements.
“We can go in and make pull requests to their code to update those terms, but it is a long process.”
According to Earl, the considerations are many. Jenkins is an international community, so the replacement terms will need to work well in English as well as other languages. They’ll also have to make sense contextually — some terms may need one replacement for web interfaces and another for server applications, for instance.
Then comes implementing the changes. Editing the user interface and documentation are as simple as executing a find-and-replace. But replacing terms in the source code itself creates challenges. New class names may interact poorly with older versions of Jenkins or with the project’s 1,500 user-created plug-ins, Earl said. And the creators of those plug-ins could continue using the old terms, if they chose.
“We have to find ways to encourage those people to make the changes,” he added. “We can go in and make pull requests to their code to update those terms, which is something we’ve done with the replacement of the term ‘slave’ over the past few years. But it is a long process.”
How You Can Foster Change Beyond Terminology
Words matter. Language constructs our reality, as Beasley and Hoyes noted. Whether or not we notice it, it’s the air we breathe.
Does that mean that codebase changes will translate into better representation and more opportunities for Black developers?
“No,” Earl said. “Is it going to solve all the world’s issues that we changed a term from ‘slave’ to ‘agent?’ Absolutely not. People have to actually get up and do something. We should be consistently looking for ways to include contributors from all different walks of life. And if we can help specifically some of these groups who are marginalized and oppressed, I think that's awesome.”
“Is it going to solve all the world’s issues that we changed a term from ‘slave’ to ‘agent?’ Absolutely not. People have to actually get up and do something.”
Terminology isn’t enough — companies and projects must purposefully diversify, Earl said. But efforts shouldn’t stop there,either. What’s equally important as bringing in more minority participants, Beasley noted, is making sure they’re supported once they arrive.
“It’s great that there’s a focus on terminology and coding, but who gets promoted when two people walk in the room?” he asked. “How do we treat differences and diversity and allow all ideas to come forward?”
Beasley and Hoyes shared some ways they believe individual developers can build on codebase changes to fight racism and create more opportunities for Black technologists:
Don’t Over-Rely on Your Network for Recruiting
Black founders are frequently passed over for venture funding. That leads to fewer Black founders — and more white founders — recruiting from their personal and professional networks, which often include people who look like themselves.
That’s systemic racism, Beasley said — it goes beyond any single person, interaction or institution. To counteract it, the industry must work from the top, with who gets venture funding, as well as the bottom, with who gets invited to interview.
Call Out Unfair Interactions
Hoyes described an incident when a client seemed visibly threatened by her presence and authority. Her white colleagues witnessed the interaction, and commented on it later.
Sometimes, it’s best to call out racist interactions in the moment. (We call out people’s behavior when it affects clients,” Hoyes said. “Why not when it affects people of color?”)
Other times, it’s better to debrief about the behavior after the fact, Hoyes said. Black employees shouldn’t have to wonder if anyone else noticed what happened.
“It’s very comforting when someone says, ‘I saw what that person did,’” she said. “That’s half of it, bothering to acknowledge it. That makes my environment so much more hospitable. You can’t put it on people of color to point it out all the time.”
Make Racism Fireable
Everyone has implicit bias. But some people exhibit intentional bias in the workplace when they say racist things, harass Black employees, prevent them from earning promotions or leading projects — or knowingly allow others to do the same.
Those people should lose their jobs, Beasley said. Campaigns against sexual harassment and assault have led to many public changes in company leadership, he added — a real anti-racist movement would likely do the same.
“It’s not cool to allow those secrets to persist, because they will just keep going on,” he said. “We have to be OK talking about race. We have to get intentional. We have to out the bad people.”
Acknowledge Incidents of Racist Violence
When Black employees show up ready to do their best after racist violence occurs in your city, state or country, that’s a testament to their excellent job performance, Hoyes said. Don’t let them start the day without acknowledging what happened in your company communications.
Stop Interrupting
Pay close attention to who gets to talk and who tends to jump in.
Expand Your Diversity Efforts From Recruiting to Retention and Promotion
Leaders at Blacks in Technology consistently hear from companies that say they “want to hire more Black people,” Beasley said. But the conversation can’t end there. Do those new Black employees feel supported enough to stay at the company? Do they get promoted?
Blacks in Technology has an onboarding program for companies’ senior leaders, in which new executives meet with a roundtable of Blacks in Technology representatives to discuss some of the challenges Black employees experience in the workplace. It also has a mentorship program that connects young people of color with professional mentors from the organization’s network.
“They may feel isolated, they may feel alone, they may not feel comfortable talking to the HR department,” Beasley said. “They may not feel the solidarity of others saying, ‘You’re not alone, baby girl, it’s happened to me too.’”