Linux Elitism: It’s a Fact
(NOTE: This post is getting hits almost three years later. Many Linux fans still don’t get it. More explanation can be found here.)
Context: I use Linux. It’s the best there is, particularly for the way I work. I thank God for Linux every time I put my fingers on the keyboard, even though I know a huge number of Linux developers and packagers don’t care about God. Perhaps that’s part of the problem, but I’m not in a position to say. What I know is the folks behind Linux are quite elitist in at least one sense of the word: They are only interested in dealing with their own kind, and have no interest in what most computer users want.
Jeremiah T. Gray says Linux is not elitist. However, he refuses to actually answer the question. Linux as a community is exclusive, though not uniformly be intention. If it were a conscious choice it would be easier to prove it, but I believe we can make a case for disputing with Mr. Gray. As my friend, Jonathan Brickman says, Linux is elitist because the Linux community refuses to acknowledge the vast majority of computer users want something a little different than Linux people want. So much so that trying to adapt Linux to serve that market is a major problem. He should know; Jonathan has been working very hard at finding a way to make a Linux distro which actually meets that demand, and the existing corpus of Linux product is fighting every step of the way.
I’m not in a position to prove this by massive user surveys. I’m not sure that would serve any purpose, since it would surely result in skewing the sample, as the subjects would have to be self-selecting. Rather, I base my argument on the only thing I have which no one can attack: My experience serving hundreds of clients who are running Windows, and a few running other things. They all know I prefer Linux, and most of them probably understand why, because I’ve advocated for Linux since I first began using it. The one thing sticking out in my mind after the last decade or so is my clients’ lack of interest in upgrading. The first response spilling out of the brains and mouths of the Linux community is how wrong this is. Fine, make all the technical, or even moral, arguments you want about how wrong it is for people to avoid change. That’s a good excuse for refusing to deal with the very real human race out there who need you most. I contend, from the billions of folks out there who actually use a computer, it’s a tiny slice who are willing or interested in upgrading and changing what they use. Sure, they may wish for this or that small feature change, but if that change came at the cost of having to learn it all over again from scratch, most would say, “No.”
My friend, Mark Falcon, lays out an example of breakage typical with Linux upgrades:
[Y]ou can imagine my frustration when I found out that my VectorLinux of 5.9 will be replaced soon by the latest and greatest update. Now I will give them an A for effort because they provide a program that allows you to save your “stuff” to be used after you reinstall but that doesn’t cover all the customization you do. Things like background pictures, number of desktops and their names, iptables changes you have made to get things like VNC and file sharing working, and on and on the list goes. I’m sorry but I’m tired of updating.
This seems to be the norm for Linux distros, not just Vector. I can’t say what response Mark may have gotten from his complaints on the VectorLinux forum, but I’m willing to bet they were unsympathetic. Indeed, when I have broached the idea with various other Linux distro representatives, and folks who spoke for various projects used by just about every Linux distro, it ranged between, “Sorry, that’s the way it is,” on one end, and words of hostility unprintable on the other end. There is no room in their minds for the concept of a stable release, with some maintenance to keep it working and secure. There is no maintenance at all. There is only the push to the next version.
The next version is seldom a trivial upgrade. If only a couple of projects here and there did this, no one would complain much. Instead, it seems there is no project doing it any other way. Worse, a vast sweep of product which is called “Linux” is all so deeply interlocked, you rarely ever get to upgrade just one thing. This is the source of the phrase “cascading dependencies.” Every project is related, and all are moving forward. To update any single element of the whole requires updating almost the entire system itself. Every fix is rolled into an upgrade, but God forbid anyone should ask for a fix to be applied to a previous release. If you aren’t mentally programed to upgrade continuously, either from the source or through the packagers for your distro, you aren’t part of the community — you don’t belong.
The vast majority of computer users can’t fathom such a mindset, and can easily explain the problems with it. They want something they can install, run for as long as the hardware works, and only apply a few patches and updates. They don’t want to upgrade, and I believe they shouldn’t have to. There was nothing inherently broken on some really good releases of certain Linux distros back in 2000, for example. There are machines which kept running those distros for a good long time. In fact, so powerful is this concept, the two largest commercial Linux firms (RedHat and Novell) focus their sales on releasing distributions they support for seven years. Because this is where the mass demand is, those two go through the hassle of hiring developers who will work out how to apply patches back to older versions of software so it won’t disturb a working system. This is what most of the world expects.
Does the Linux community want mass adoption? I have to wonder if that isn’t just an excuse to whine, and I consider Mr. Gray’s piece dangerously close to that. If the folks developing Linux aren’t going to meet the masses where they are — it’s called “serving the customer” — they can’t pretend to offer them anything. Linux will remain an exclusive club of snotty elitists to the extent they refuse to consider stable releases and long-term support.