Why Github’s “main” concern is at best lazy posturing

Tong Qiu
Codehesion
Published in
4 min readJul 5, 2020

If you work in the tech industry, you’re probably aware of the recent push for more “racially neutral” language in terminology. Github is renaming its master branches to main. Twitter has just published its guidelines for more inclusive language. Chromium too has something similar.

I take no issue with “more inclusive language” in principle. But I think there is some really questionable logic behind some of these proposed changes. In this post I will focus on Github’s renaming of “master” to “main”. I plan to follow with a second post on why blacklisting “blacklist” is not only too ironic to be allowed (if irony had a whitelist, oh wow this has gotten meta-ironic), but a form of censorship that patronises the intelligences of even the dimmest of us (I’m probably not supposed to use dim to mean unintelligent any more either, am I?).

So, onto Github. Its renaming of “master” to “main” is in response to the claim that the use of “master/slave” terminology evokes black slavery, a still gaping and raw wound in modern race relations, and that association creates a non-inclusive or even hostile work environment for black software developers. While I can understand and sympathise with that argument, the problem I have with Github’s change is that there is no “slave” in their terminology. There are no slave branches (of course, you can name your branches whatever you want so maybe some people call theirs slaves, but in all my years working with Github and Gitlab across various companies I have never encountered a branch called slave). So now are we saying that the word “master” itself is problematic? I find that harder to buy.

Maybe it could be if its context clearly implies the presence of slaves, even if they are not named (and even this I would find tenuous). But if you actually read the definition of the master/slave terminology in software, you’ll find that it doesn’t even describe Github’s branching model. The master branch doesn’t control other branches. Other branches are used as working drafts to then update the master branch. If anything, it’s perhaps closer to the notion of “master mixes” in music in that it’s the final published version, and I don’t see anyone calling that racially non-inclusive. Yet.

So what can I conclude about the motivations behind Github’s change, forcing its 40 million users to update their references to their master branches? I’m afraid the only conclusion I can draw is that they’re bowing to public pressure to show some kind of — actually no, the right kind of — response to the BLM movement. And it’s a lazy one — they didn’t even conceive of the idea that master/slave terminology should be replaced by something more inclusive. According to this Vice article, that idea goes back to 2003 and programming languages such as Python and Drupal have already replaced those terms. From where I’m standing, it looks like Github got into a branding panic about how to show their support for BLM (because apparently silence is violence now) and this seemed like a visually pleasing thing to do that would make international news. Never mind that it’s an empty gesture.

Furthermore, this kind of empty gesture is worse than useless, I believe it is actually harmful to the cause of racial equality and inclusion in our industry. Both the BBC article and a colleague of mine quoted this tweet from Una Kravets of Google in justifying the change: “If it prevents even a single black person from feeling more isolated in the tech community, feels like a no brainer to me!”

Firstly, I have not heard or read any evidence that this change — just removing “master” when it’s not contextualised with “slave” in any way — has or will make a single black person feel less isolated in the tech community. If anything, this over-the-top insistence on seeing race where it doesn’t even exist could well make black engineers, who are often already painfully aware of being in the minority, feel even more self conscious. They may fear resentment from their white colleagues who bemoan this as PC gone mad, or an unnecessary policing of language.

Secondly, it’s a very naive statement that assumes the feelings of individual black people is the only measure of importance. It completely fails to consider the potentially negative consequences. One, as mentioned above, could be that it actually makes black people feel more isolated or tokenised. That one is speculation on my part, but this next one isn’t. It could cause, and indeed has caused, backlash against the whole movement to improve racial inclusion in tech. Is it really worth one black person feeling better in their job to push thousands of others, who had been in favour of improving diversity and inclusion in the tech industry, into a more suspicious stance on initiatives that try to do this? To me, it doesn’t seem like a “no-brainer” at all, rather it suggests that the person saying this didn’t really use their brain.

Finally, the argument is itself extremely exclusionary in its use of the claim that it’s a “no-brainer”. This implies that if you disagree with the statement, you are even more stupid than a person without a brain. Such a dogmatic statement in favour of inclusion is laughably, but also tragically, ironic.

Given all this, the most generous interpretation that I can give of Github’s change is that it is lazy posturing, a cynical branding exercise. The least is that it’s a net negative in the quest for improved racial inclusion in the tech industry.

--

--