Benefits for LWN subscribersThe primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!
Arguments about terminology are not rare in our community; words are powerful tools, so we want to be sure that we are using them in the correct way. But, naturally, opinions on what is "correct" may (and do) differ. Discussions on the use of loaded terms like "master" and "slave" have been ongoing in the community for some time, but recent world events have given them a new urgency. Some projects have made changes in the past, but the current wave of changes seems likely to be far larger.
The idea that our choices of words matter is not a new one in this community. The classic example would have to be the Free Software Foundation (FSF), which has tried to change our use of language since the beginning. Consider the FSF's lengthy "words to avoid" list for no end of examples:
We don't describe free software as an "alternative" to proprietary, because that word presumes all the "alternatives" are legitimate and each additional one makes users better off. In effect, it assumes that free software ought to coexist with software that does not respect users' freedom.
The FSF has often refused to talk with news organizations (including LWN) without an advance promise that at least some of its word-use proscriptions would be followed in any resulting article. The loss of coverage resulting from that condition is, seemingly, considered a price worth paying in order to keep distance from perceived illegitimate use of loaded terms.
In the wider community, terms like "master" and "slave" have been the source of discomfort for some time; some projects have moved away from those terms in recent years. Current events — and not just in the U.S. — have raised awareness and greatly accelerated efforts in this direction. The topic has recently come up in the kernel community, which has also been discussing a proposal to replace "blacklist" and "whitelist" with "denylist" and "allowlist".
This discussion is not just limited to the kernel, though. The Git community is debating renaming the default "master" branch to something else — a change that is already being made at major Git-hosting companies and which is almost certain to be adopted. Similar discussions are being held in the Ansible community, the curl project, the Go language community, the OpenSSL project, the PHP community, and beyond. The Python community mostly eliminated these terms in 2018.
Needless to say, there has been opposition to these changes. Some of it comes from the usual spontaneous sock-puppet accounts that proliferate around this kind of discussion — but not all of it. Opponents make the point that words with the same spelling have different meanings in English, and that a slave device has nothing to do with an enslaved human. Making these changes, they argue, distorts the language, creates endless code churn, and confuses users in support of a sort of political correctness that does little, if anything, to address the actual problem of systemic racism. There is also a slippery-slope argument that can be heard; will one get into trouble for claiming to have mastered a difficult subject or listing one's master's degree on a resume? What should the kernel's position be on red-black trees?
What should we do?
Unsurprisingly, your editor has an opinion on this subject, though it has shifted some over the years. Words are important, they are the tool with which many of us ply our trades. The English language requires speakers to keep multiple possible meanings for a word distinct in their minds, and a slave controller really does have nothing to do with an enslaved person. Attempts to control the language used by others are fraught at best and outright dangerous at worst; Orwell dwelt long on Newspeak in 1984 for a reason.
But that is an easy position for some of us to take.
Your editor received a fairly standard 20th century American education, which presented slavery as an evil from a previous time, something that had been left behind long before our grandparents were born. To somebody with your editor's background, it is easy to see slavery as being about as relevant as the horse-and-carriage trade — not something that often comes to mind, and certainly not something that should be driving 21st-century software development.
Recent events, though, have made it clear — even to those of us who were happy to not question this view — that the story of slavery and the wider racist systems around it is not yet finished. There are many people who are still living in the middle of it, and it is not a nice place to be. We are not so enlightened as we like to think we are.
If there is no other lesson from the events of the last few weeks, we should certainly take to heart the point that we need to be listening to the people who have been saying, for many years, that they are still suffering. If there are people who are telling us that terms like "slave" or "blacklist" are a hurtful reminder of the inequities that persist in our society, we need to accept that as the truth and act upon it. Etymological discussions on what, say, "master" really means may be interesting, but they miss the point and are irrelevant to this discussion.
In other words, we should make those changes. It's a tiny step, and it does little or nothing to address the real problems, but it is a statement of support and a way of being more inclusive toward a large subset of humanity that is severely underrepresented in our community.
The grungy details
Even after we have made the decision to listen — as it seems likely we will do at this point — execution will not be easy. Consider the scope of the problem in the kernel community, for example; quick fixes are not to be had.
The kernel has over 41,000 occurrences of the word "master" in its repository, and over 26,000 of "slave". "Blacklist" appears nearly 1,000 times, while "whitelist" has over 600 occurrences. Any attempt to change all of those in any near-term way would snarl kernel development in general and bring the work of thousands of developers to a halt. It would break the agreement in how kernel code and various specifications (and device datasheets) use terms, with unpleasant effects on the ongoing maintainability of the code. Changing names in exposed data structures would likely break the compilation of numerous applications.
So a massive search-and-replace operation seems out of the question. What the kernel community can do, though, is to decide not to accept submissions that add the use of these terms in the future. When proposed additions use terminology from a specification maintained by others, those terms could be changed in a predictable way or, in some cases, the submission could be refused until the specification is changed. Those changes seem likely to happen; the same sorts of conversations are ongoing in standards groups too. Meanwhile, individual subsystems could make changes where they make sense, at a pace that can be absorbed without disruption.
We appear to be in one of those times where attitudes undergo a fast shift
and, hopefully, some sort of meaningful social progress is made. There are
a lot of things we can be doing in the free-software community to support
those changes — changes that, with luck, will serve to expand our community
and make us that much stronger. It would be a poor time to be
standing in the way of this progress. Thinking about the words we use and
making changes to avoid those that are unnecessarily hurtful seems like a
small thing to ask.