It ranges from incredibly easy to incredibly hard to change existing content.

For documentation and some code you can probably just do the programmer equivalent of a find + replace. Blacklist/Whitelist is probably on the easier side.

But most of the time its more difficult. Things are referred to many times in many different places. Using find + replace on the word "master" will almost certainly include other references to the word outside of the master/slave context. I believe one of the statistics was that the linux kernal has ~30k instances of the word master - though that may be more of a comment on the size of the linux kernal than anything else.

And even more daunting is APIs. Basically many programs and applications provide an interface for external programs to interact with them. For example, facebook might provide an API call that lists all of your friends, or lists the email addresses in your profile. When any of those refer to something that gets removed, everyone has to change it. So for example, if tildes.net/api/blacklist provided a list of websites that are prevented from being posted to Tildes, then updating it to tildes.net/api/denylist will break every piece of software that uses that API call (mobile apps, browser extensions, personal scripts, etc). You can somewhat mitigate this by having the old call to blacklist forward to denylist, and eventually phase it down the road - but even then its highly likely that some piece of code doesn't get updated and it will break something eventually. (Note - I just made up a random example, I don't know that tildes has a blacklist/denylist api call)

But its a good question. A lot of programmers are technically minded people and are looking at things with a cost/benefit mindset. Changes like master/slave and blacklist/whitelist are generally recognized to have significant benefits that outweigh the costs of changing them. In master/slave, it removes language that discourages many folks of color from going further into computer science. With Blacklist/Whitelist, the benefit is that twofold in that we stop associating black == bad (regardless of whether the etymology has a concerning history), but also we provide a more accurate term with denylist/allowlist - which helps a lot of non-English speakers to parse the meaning from the word rather than "memorizing" that blacklist is a list of bad things. As someone put it, a deny list is a list that denies. A black list doesn't make sense as a list that blacks. Master/Slave also can benefit from more accurate terms, but they have a much wider definition and use, so that may depend on the context.

But then going to some of the other suggested changes, one is to replace the "master" branch in git with the "main" branch (or another similar term). This one has seen a lot more pushback, and part of the reason why is that for many programmers, the cost/benefit analysis doesn't add up. A lot of the obvious arguments about master/slave don't necessarily apply to master branch. There is no slave branch, the history of the word isn't obviously rooted in racism (the creator was not a native English speaker or American), and the practical use is a master copy of a key or a master record. For many programmers, the benefits don't appear to outweigh the costs of making the change.

Of course, theres other people who are not doing cost/benefit analysis and are objecting for other reasons ranging from stubbornness to racism to censorship/slippery slope fears and all the way to concerns that focusing effort and goodwill on these small changes will detract from "real" changes like addressing police violence.