Git is changing. GitHub, GitLab, and the core git team have a made a system of changes to phase out the use of the word âmasterâ in the development tool, after a few years of heated (heated) discussion. Proponents of the change argue âslavery is badâ, while opponents inevitably end up complaining about the question itself being âoverly politicalâ. Mostly. And, with the tendency of people in the computer science demographic to⊠letâs call it âconservatismâ, this is an issue that gets very heated, very quickly. I have⊠thoughts on this, in both directions.
Formal concerns about problematic terminology in computing (master, slave, blacklist) go back as early as 2003, at the latest; this is not a new conversation. The push for this in git specifically started circa 2020. There was a long thread on the git mailing list that went back and forth for several months with no clear resolution. It cited Pythonâs choice to move away from master/slave terminology, which was formally decided on as a principle in 2018. In June of 2020, the Software Freedom Conservancy issued an open letter decrying the term âmasterâ as âoffensive to some people.â In July 2020 github began constructing guidance to change the default branch name and in 2021 GitLab announced it would do the same.
First, what role did master/slave terminology have in git, anyway? Also, real quick, whatâs git? Put very simply, git is change tracking software. Repositories are folders of stuff, and branches are versions of those folders. If you want to make a change, you copy the file, modify it, and slot it back in. Git helps you do that and also does some witchery to allow multiple people to make changes at the same time without breaking things, but thatâs not super relevant here.
That master version that changes are based is called the master branch, and is just a branch named master
. Changes are made on new branches (that start as copies of the master branch) which can be named anything. When the change is final, itâs merged back into the master branch. Branches are often deleted after theyâre merged.
It looks something like this, with each branch on its own horizontal line:
Unlike some other programming paradigms, git never used the word âslaveâ, only âmasterâ. Branches are simply referred to as branches, not âslave branchesâ. The only thing particularly special about the master
branch is its use as this master copy. When you start a git project the default branch is named master
, but thatâs all the special treatment it gets.
So why are people upset about the use of the word âmasterâ? Or, alternatively, why isnât everyone upset by the use of the word âmasterâ, and how did it ever fall into use in the first place?
The problem here is tied up in the very concept of subordination. There are a few relevant definitions of the word âmasterâ here: âchief, principal, or predominantâ, âcontrolling all other parts of a mechanismâ, and âa film used for making duplicate printsâ. All of these definitions apply to the master branch in coalescence. The master
branch is the dominant branch in the process, the first branch in an ordered list, the authoritative version. Behind all those definitions though is the common, fundamental meaning of the word; âmasterâ means something with power over something else, which demands we look at the concept of subordination.
The word subordinate (sub-order) means to be of a lower order, or lower class. This invokes some of the same ideas as incommensurability, where orders are not a matter of scale, but of category. Something in a subordinate rank is categorically inferior to all things in a superior (super -ior) rank. (see also âprincipalâ.)
This is an abhorrent concept to apply to humans, along any line. There should never be a category considered subordinate, whether delineated by race, or gender, or intelligence, or birthplace. Humans can be in a subordinate role (all cashiers are of a lower rank than their managers in the context of their job, for instance), but must not be subordinate per se. While slavery is of course the ultimate example of this, the problem of putting things (people, machines, systems) in control of humans is a persistent one, and a recurring evil in any area of life.
But is subordination, as a concept, bad, in the context of a society that historically misuses it on humans? No. I mean, it mustnât be. You have to have orders and classes and groups in the fields of mathematics, or you canât even sort things. Rank, as a concept, is as close to a value-neutral thing as you can get. But that quick âneutral concepts canât be wrongâ doesnât address the real issue.
People arenât upset at the idea of subordinate branches. The strictly hierarchical way work is done (with one master version) isnât up for dispute here, just the names used.
But also, no one is saying the word master
doesnât accurately describe that subordination-based workflow. Unlike some other cases in computer science, the âmasterâ label isnât even primarily a metaphor for human slavery.1 It isnât over-generic, and replacing it doesnât help increase clarity.
So what is the actual concern? The original Software Freedom Conservancy cites the term as being âoffensive to some people and we empathize with those hurt by the use of that term.â GitHub skips over the question entirely and just says âMany communities ⊠are considering renaming the default branch name of their repository from master.â The python issue (which was approved) just says âFor diversity reasons, it would be nice to try to avoid âmasterâ and âslaveâ terminology which can be associated to slavery.â and simply cites other similar discussion threads.
The problem is the word itself, and the very strong associations some people have with it. People arenât upset about the concept of subordination when applied to revision history, theyâre upset about the very real atrocity of human subordination, which subordination in general happens to remind them of.
It doesnât go much further than that, but it might not need to: language is associations, after all. Use of the word âmasterâ in the context of computer science is associated with use of the âmaster/slaveâ model (again, used commonly in the context of computer science) which obviously has a very tight association with the real-life atrocities of human-to-human master/slave slavery. I titled this article âIs (git) master a dirty wordâ. Thatâs not a rhetorical question Iâm pretending you asked so I can give you my easy answer, thatâs the real question at stake here. Has the word been dirtied? Is that even a thing that can happen? Like with far too many questions, this seems to fall all the way down to linguistics.
So, if itâs only the word association⊠is that enough to warrant major changes?
There is a lot of fourmlike chatter about this topic online, but I think my two favourite artifacts to probe are NISTIR 8366 and draft-knodel-terminology
.
NISTIR 8366 is the National Institute of Standards and Technologyâs Interagency Report titled âGuidance for NIST Staff on Using Inclusive Language in Documentary Standardsâ, and functions as a standardized guidebook for choosing appropriate language within CS. Itâs a short document â only 8 pages of content â that covers a wide range of topics. Section 4.1 is a bullet-point list with headers like âAvoid terms that assign a gender or sex to inanimate objectsâ and âAvoid colloquialisms, metaphors, similes, idioms, and other unnecessary jargonâ. This is the section where the document first brings up âmaster/slaveâ, under the header âAvoid terms that perpetuate negative stereotypes or unequal power relationshipsâ. The same document later gives the example âThe terms âmaster/slaveâ to describe a model where one device or process controls another as subordinate should be avoided.â
I find this to be an interesting topic to interrogate. This says that even under the premise of describing a subordinate relationship, the âmaster/slaveâ metaphor should be avoided. Do terms that describe unequal power relationships really perpetuate them? What if â as in computer science â unequal power relationships can actually be the desired and correct outcome?
draft-knodel-terminology
, meanwhile, is âTerminology, Power, and Inclusive Language in Internet-Drafts and RFCsâ, a draft for the IETF (a major internet standards body) written by Mallory Knodel. Itâs specifically about the use of inclusive language within RFCs (Requests For Comment, internal memos) and makes a strong case based on the importance of effective communication. It dedicates a full page to the master/slave metaphor specifically:
Master-slave is an offensive and exclusionary metaphor that will and should never become fully detached from history. Aside from being unprofessional and exclusionary it stifled the participation of students [âŠ]
âŠ
Ultimately master-slave is a poor choice since it is 1) being used less frequently already 2) in a variety of applications 3) to correct perceived exclusionary effects 4) at the request of concerned members of the technical community.
It then proposes a few general-purpose alternatives, including âprimary/secondaryâ (based on authority) and âprimary/replicaâ (based on originality). Unfortunately, neither of those map well to branches; calling a branch âsecondaryâ is confusing terminology, as there can be many simultaneous peer branches, and, as branchesâ entire purpose is to be changed, âreplicaâ doesnât fit well either.
Another on the side of making the change, Chrome developer Una Kravets wrote:
Replying to Una:Thu Jun 11 20:45:27 +0000 2020^
1. âMainâ is shorter! Yay brevity!
2. Itâs even easier to remember, tbh
3. If it makes any of my teammates feel an ounce more comfortable, letâs do it!
4. If it prevents even a single black person from feeling more isolated in the tech community, feels like a no brainer to me!
Github Replacing âMasterâ With âMainâ is a Huge Win for Inclusion in Tech is a great article about this that points out how making minorities less comfortable (however marginally) directly harms the industry by keeping people out:
âŠrecruiters and those complaining about the (alleged) ever-elusive âpipeline problemâ of getting minorities into tech have no idea how much of a road block unnecessarily non-inclusive terms like âmasterâ and âslaveâ have in causing many minorities who do enter the âpipelineâ to leave at higher rates than their white counterparts.
However (and this is the reason this article is âgreatâ, unfortunately) right beneath this excellent point is a section titled ââMasterâ Almost Caused Me to Quit Software Engineeringâ in which the author demonstrates a failure to understand gitâs conceptual model:
Imagine every time you save a file, instead of clicking âsave asâ or âopenâ for a file you have to explicitly type âmaster can I save thisâ and âmaster please open this.â Thatâs how Github works â thatâs what Software Engineers do!
For those of you who are technical, you know that sometimes âmasterâ will give you want you want, but other times you essentially have to beg âmasterâ for the updated version of your files.
Why is this called âmasterâ anyway? What am I even doing here at 3am dealing with âmasterâ like this is the 1800s?
This is very emotionally rich language, and I understand how feeling this way would be incredibly discouraging. Factually, though, itâs completely wrong. master
is a document, not an administrator; developers donât ask it for things, it doesnât grant you things, it isnât an actor of any kind. There are some compsci âmaster/slaveâ models that are like this, but git isnât one of them. The notion of the developer/software interaction here is incorrect. Whatâs being described here is a frustrating learning curve exacerbated by the language the software used. Exacerbated to such an extent that, at the time this article was written, the author seems to have given up on understanding entirely, which isnât an outcome anyone wants.
I think this is one of the legitimate things that frustrate the master
holdouts. It often seems like the proponents of making these changes are much more focused on the emotional impact of the language than they are on the conceptual model of the thing they want to change. With a case like the one above, the question becomes âIf he understood the model, would he even have the complaint? And does his distress prevent him from understanding the model?â If the people pushing for the change arenât focused on the mechanics, the people who only care about the mechanics see the argument as flimsy. And when the individual arguments for a cause seem flimsy, the cause as a whole feels flimsy.
As seen on the python thread, the objections to master
can seem like âvaguely formed notionsâ rather than pressing issues:
Raymond Hettinger wrote: Mostly, I donât think these changes should be made, particularly in cases where âslaveâ isnât mentioned at all. The word âmasterâ is used in many contexts where master/slave doesnât apply (such as âmaster keyâ).
âŠ
If a particular passage is demonstrably unclear or offensive, it should be changed; otherwise, we shouldnât let vaguely formed notions of political correctness shape other clear uses of plain English.
As far as I canât tell there isnât a single instance where the docs use âmasterâ as a reference to human slavery or where the use could be seen to imply an endorsement of that notion.
This is a fairly typical argument. âIf thereâs a specific issue with a specific section, it needs to be changed. If thereâs an inappropriate reference to actual human slavery, that could be in such poor taste that a change is demanded, but there isnât.â
I think part of what people are complaining about when they say this movement seems âpoliticalâ is their belief that the intent behind the change should not be a significant part of what makes the change itself good, that itâs insufficient for the notion to be the driving factor. For the long-term structural changes being proposed to be valid, the changes need to be able to stand on their own, not completely dependent on their specific cultural context.
Hereâs my devilâs advocate thought experiment on this: if the faction proposing these same changes had the opposite background, would that make them horrifying? Imagine a cause led by historical revisionists looking to whitewash the atrocities of human slavery, purging references to the concept in an attempt to prevent people from being reminded of their history. And, in an attempt to do this, proposed exactly the same language change. Would that be a monstrous thing to do? Would that make the change itself a monstrous thing to implement? If the ânobilityâ of making the change is the kind of thing that can be impacted by the mere intentions of the proposers, is it the kind of change that should be made to core infrastructure?
There are other⊠less sophisticated arguments out there for keeping master
, though. For instance, letâs look at some of what one of these people from the mailing lists has to say:
Felipe Contreras wrote: Itâs not a coincidence that nobody found the term problematic for 15 years, and suddenly in the height of wokenessâ2020 (the year of George Floyd, BLM/ANTIFA uprising, and so on)â
oh god, letâs stop looking at that now. I mean, I guess itâs not a total surprise thatâs how mr. anti-woke, eminent discusser breaks the ice, the git. There are actually some half-decent points buried the heck in there, but urgh is it painful to read.
The problem is people like this approach the issue from a defensive, dire mindset that doesnât allow for any good faith or empathy with the âother sideâ. Sure, there will always be some people who take up causes in bad faith, sure, but to demand that everyone is faking their distress is dishonest, and lazy. More importantly, the combative stance is not one that allows for these issues to be resolved peacefully. It fractures a community of people who are ostensibly working towards a common goal into factions at each othersâ throats over perceived attacks that are often simply miscommunication.
In this enormously charged issue, filled with people throwing around words like âdiversityâ or âsjwâ or âpolitical correctnessâ, the actual positions seem to come down to âChanges should only be made if demonstrably, mechanically necessaryâ and âChanges that make a group of people more comfortable should be made.â Master isnât some magic word that git needs to use; that isnât the complaint. The concern is about the necessity of the change, and that the change replaces a more accurate metaphor with a less accurate one.
Which is right? I donât know. Even after all that, I find myself tending towards the former. I look at the latter from a project management perspective (where frivolous change requests must be guarded against with ferocity) and think âthat way lies madness.â As a language guy, too, I feel like âmasterâ describes the actual relationship of subordination thatâs being described much better than the replacement (âmainâ). It almost feels like a lesson in whitewashing uncomfortable words away while keeping the structures they describe. In this case, though, the structure is fine; itâs just the word that isnât â democratically, for better or worse.
I realize Iâm teetering on the edge here of out-and-out saying âif you are made uncomfortable by this, you are wrongâ, which is certainly something I did not set out to do, and something I categorically dislike saying. But right now, it seems to me like that might actually be the case here.
More inclusive language in computer science is definitely a good thing, and we absolutely donât need to be using slave language to describe things like producer/consumer relationships. (Honestly, an awful lot of things got named master/slave for what seems less like metaphor than laziness. A lot of replacements have been in cases where the master/slave metaphor was technically inaccurate or misleading.)
I picked git to focus on here because itâs one of the cases where thereâs the least clear need for change, and therefore both the most room for debate and the most interesting conversation to be had. We need to be using the right language for the job, and we need to be mindful of the effects words have on other people â something the computer science community is particularly bad at. But in cases where the underlying relationship really is one thing being in subordination to another, maybe itâs good to be in the habit of describing them accurately and honestly.