I learned of an interesting trend in software circles today. There has been a move to rename "master/slave" architecture into other terms, such as "master/worker", "leader/follower", etc. in an effort to remove the word "slaves" from code, docs, etc. I first noticed it done in Hadoop 3.0. But it got a lot more attention when Django made the change and Mozilla donated 15K to BuildBot to fund similar work. Googling around, it seems Jenkins, Drupal, and Mesos also did the change in the last few years. I'm sure there are more that I missed and am just not searching the right terms.
As you might imagine, this has lead to quite politicized discussions on bug/issue trackers. Are we going "too politically correct"? Couldn't engineer hours be used more effectively? You can imagine all of the discussions that could follow.
But I found this comment from the Django issue tracker on this subject to be quite enlightening.
But I found this comment from the Django issue tracker on this subject to be quite enlightening.
"I'm very glad for this change because as a PoC I felt very uncomfortable seeing and using this terminology in my code"
We can choose to be more inclusive and welcoming to all people that may code. Or we can choose to stick to the past terms based on a somewhat arbitrarily chosen naming from eons ago. As a group, I think we should try to make programming more "inclusive" than "exclusive". I wrote about this a bit awhile back regarding the use of 0xB16B00B5 (i.e. "Big Boobs") in the Linux kernel and how such language can make programming seem like something for boys instead of girls.
I know there are those who think it shouldn't be changed due to it's large legacy meaning/usage and the fact that it's clearly not related to human slavery. I'm sure there are others that feel that such as a change is just "being too politically correct."
I was trying to think of an example in software history that would serve as a good illustration of how it's a good idea to change these terms, even though they become nearly defacto terminology.
I couldn't think of one. Some of it just might be because software is too "new" of a thing still.
I did end up thinking of one in medical history related to Down Syndrome.
I know there are those who think it shouldn't be changed due to it's large legacy meaning/usage and the fact that it's clearly not related to human slavery. I'm sure there are others that feel that such as a change is just "being too politically correct."
I was trying to think of an example in software history that would serve as a good illustration of how it's a good idea to change these terms, even though they become nearly defacto terminology.
I couldn't think of one. Some of it just might be because software is too "new" of a thing still.
I did end up thinking of one in medical history related to Down Syndrome.
According to the wikipedia page, Doctor John Langdon Down first characterized Down Syndrome in the 1860s and initially called people with it "mongoloids" because he considered the facial features to be similar to those of "Mongolians". It wasn't until the 1960s that the term was official changed to "Down Syndrome", named after the doctor that characterized it.
I hope to most readers here that the reason for the change is obvious. The term "mongoloid" was often used as a pejorative for people of Asian descent. It was simply embarrassing to continue to use such an outdated/racist word to describe a genetic disorder going into the 1900s. According to Wikipedia, it wasn't really until the 1970s that the term really disappeared.
I can't help but think, it took about 100 years for the term to be officially changed from it's original naming to the modern one. That's a long time. So that's a lot of medical history that had to be changed. I believe that the change was due to the realization that while the original name was widely used in the medical community, times do change. And as times change, it's perhaps best to move on and adapt to that change.
So I think the software community can change too. So I decided to make the changes in Magpie. While I can't do it everywhere, as some tools such as Spark and Hbase still rely on the term, perhaps this is the beginning of the change throughout. Once projects like Spark and Hbase migrate, I can propagate it further.