Linux kernel coders propose inclusive terminology coding guidelines, note: 'Arguments about why people should not be offended do not scale'

Move won't fix 'brutal system of human misery' but aims to encourage participation

In the light of the 2020 "global reckoning on race relations" the Linux kernel developers have stepped up with proposed new inclusive terminology guidelines for their coding community.

The proposal came from Intel principal engineer Dan Williams and won support from other Linux maintainers including Chris Mason and Greg Kroah-Hartman.

Words to be avoided include "slave", with suggested substitutions such as secondary, subordinate, replica or follower, and "blacklist", for which the replacements could be blocklist or denylist. The proposal has allowed for exceptions when maintaining a userspace API or when updating a code for a specification that mandates those terms. The existing Linux kernel coding style, described here, and has made no mention of inclusive language.

The proposal is to add a new document, to be called Linux kernel inclusive technology, which will give the rationale for the changes. Referencing the fact that "the African slave trade was a brutal system of human misery deployed at global scale," the document has acknowledged that "word choice decisions in a modern software project does next to nothing to compensate for that legacy."

The goal, though, will be to "maximize availability and efficiency of the global developer community to participate in the Linux kernel developer process."

"The revelation of 2020 was that black voices were heard on a global scale and the Linux kernel project has done its small part to answer that call as it wants black voices, among all voices, in its developer community," the proposal read.

The proposal also noted that "non-inclusive terminology" has a "distracting effect" and "injures developer efficiency." Of the anticipated backlash, Williams stated: "Of course it is around this point someone jumps in with an etymological argument about why people should not be offended. Etymological arguments do not scale. The scope and pace of Linux to reach new developers exceeds the ability of historical terminology defenders to describe 'no, not that connotation'."

While most will welcome the idea of adopting inclusive terminology, there are dissenting voices particularly when it comes to the rationale. Should the new inclusive terminology document be official? "Developers can honestly disagree about this sort of thing, while supporting the aim of using inclusive language. That's why this file shouldn't be in the kernel tree," wrote IBM Distinguished Engineer James Bottomley.

Google developer Kees Cook argued that the rationale document "provides rebuttals to many of the specious arguments against inclusive terminology (and it could perhaps gain more, as we've already seen in this thread, against slippery slope arguments). It also attempts to acknowledge what this change in the kernel processes provides to the world in general."

Another concern is that replacing commonly used terms with less well-known synonyms could itself be a challenge for non-English speakers. "By changing terminology that has been in use for so long that it's been imported into other languages directly or is common enough that non-native speakers know what it means might have exactly the opposite result by excluding people that aren't native English speakers and can't decode synonyms that are obvious to a native speaker," wrote Daniel Palmer.

Finding consensus on such matters is not easy, but if adopted, the kernel will be one of many projects where inclusive code is encouraged, including the Google-sponsored Chromium project which has stated that code should be gender-neutral and racially neutral. GitHub CEO Nat Friedman said the company is working on dropping the term “master” from its default branch structure.

The MySQL team posted last week about terminology changes coming to MySQL, proposing use of the words source, replica, blocklist and allowlist in place of terms where "the origins of these words are negative."

Twitter Engineering has posted a list of non-inclusive terms it wishes to avoid in its code, including terms like “man hours”, “dummy value,” and “sanity check.”

"Words matter in our meetings, our conversations, and the documents we write. We know there’s still a lot of work to do, but we’re committed to doing our part," said Twitter. ®