KDE will soon be releasing version 4.0 of its desktop environment. But KDE has a deep, dark secret – it engages in slavery. Actually it's not a secret, they tell you straight up, they use slaves throughout its infrastructure. And since February is Black History Month in the U.S., I feel compelled to speak out against this injustice. Slavery anywhere is a threat to freedom everywhere, even in software.
For those of you who don't know KDE uses routines it calls IO-Slaves to perform various interface tasks. When I first heard (about 3-4 years ago) that KDE named these routines "slaves" I thought to myself, here we go again. I went onto some KDE forums to get them to use some other terminology for these routines. I (and others) obviously couldn't convince them to change this terminology then, but maybe I can tweak their consciousness now to reconsider the message they are putting out behind the use of the slave paradigm.
While writing this piece I didn't have time to search and find some of the discussions I remember, particularly from the 1970-80s, carried out in various trade magazines letters to the editors, articles, and usenet forums, about the need to abolish the master-slave terminology paradigm, prevalent in electronics and software then. It seems the developers at KDE need to see these discussions, and understand why, almost universally now, you no longer see hardware and software processes and relationships referred to as master-slave, but rather as parent-child, client-server, and other such more socially acceptable (and functionally accurate) terminology.
And for those maybe too young (or insensitive) to remember what the big deal was be about why there was a push to have this terminology excised from the fields of electronics, software, et al, well it was simple. During the '70-80s there was a large influx of Black and women students into colleges then, which caused to be challenged virtually everything about the status quo paradigms in existence. And a lot of that centered on attacking language constructs that were demeaning and oppressive to non-whites. For ultimately, the power to define is the power to control.
As more non-whites entered the sciences and engineering (as I did) we were confronted with the legacy of offensive terminology which most whites never stopped to think about as being offensive. The master-slave paradigm of labeling hardware boards and interactions was virtually ubiquitous, which was then passed along to the software world, especially after microprocessors and digital electronics began to replace analog systems. So the language constructs used with hardware was mimicked for the new software driven systems.
So it was deja vu to see the reemergence of the term "slaves" to represent KDE's IO API, which tells you something about the mono-culture of the people who make up the KDE community. How? Well, it's hard for me to imagine any self-aware Black person sitting in a room of people trying to come up with a name to refer to their IO routines, and someone says, "hey, let's call these routines slaves" and the Black person wouldn't say, "uh, I think we should come up with a better name." But you needn't have to be non-white to recognize the destructive legacy that word conjures up.
For really, what is KDE trying to project by calling these routines slaves. After all, enslaved people are people who can be arbitrarily abused, demeaned, and killed, who have no value beside their capacity to provide uncompensated labor, who are denied all rights of person hood, and have no protection under the law. At least that's what it meant to be enslaved in the Americas.
But the KDE io-slaves seem to be a very important and essential core elements of the KDE infrastructure. They possess highly specialized functionality, are designed to provide an efficient and ubiquitous set of tools for application developers to interface to, and thus are valuable components which enhance the utility of KDE. These qualities seem to be the antithesis to those of "slaves." Maybe KDE can hold a contest to choose a better name for these routines, but it should absolutely act to free its "slaves" now.
Human slavery is still a scourge mankind hasn't been able to eradicate, as we now enter the 21st century, because it's a concept too many people still condone. The enslavement of humans will end only when the concept of slavery ceases to exist. Thus, people who produce "free" software should not promote its concept to characterize anything about the nature of their code. While we might not be able to eradicate slavery in the world of human interaction, we absolutely should be able to prevent it from manifesting in the world of free software.