The Inherent Danger in "Just Working"

I am admittedly not a normal computer user. I don't always fully grasp what's going on deep inside the operating system, nor am I always confident I'm clear on how an application is working with all of the services it requires to function. But I find it interesting, even if just on the most simple, conceptual level.

The majority of computer users want their machines to "just work." And though I like seeing how my hardware and software interact, it is preferable to have things "just work," so I can get what I need done, and then spend the time I saved doing so leisurely poking at my application's innards. There's an inherent danger in the "just works" philosophy, however.

When something doesn't "just work" on a computer, it's frustrating. I'd say when anything that you'd expect to work doesn't, it's a nuisance. But when people find the refrigerator isn't keeping anything cool, or the car engine is making knocking noises, they assume the appliance in question is broken for whatever cause. At least some of these same people, when experiencing difficulties with their computers, reach a resigned acceptance that something is broken beyond repair from the start, or (quite commonly) adopt some form of "magical thinking." I've jokingly referred to some technical difficulties I've experienced as if the machine is a cognizant being that just is feeling uncooperative -- there are many sane, intelligent people out there who, on some level, seem to buy into that belief. Your operating system, like your braking system in your car, should respond predictably to the commands you give.

Wait -- and what's this got to do with open source? A lot. It's also got a lot to do with misconceptions (not just the fear-uncertainty-doubt variety), and -- yes -- self-confidence of both end-users and programmers.

Linux usage -- if not outright, across the board, full time adoption -- has been on a healthy increase for several years. Part of this is undoubtedly due to the focus on new-user friendly distributions (such as Ubuntu, PCLinuxOS, and Mandriva) that make the now rather wide range of hardware supported by Linux "just work" seamlessly. Before we go further: This is a good thing to strive for and make new users aware of.

It's a good thing to strive for, whether the operating system you are developing is open -- or closed. I'd venture on a limb and say I've had more luck in the past three or four years with hardware working out of the box (no additional disks or special configuration needed in either GUI or textual .config file formats) in Linux than I have with proprietary systems. When I have had trouble on a closed front, getting things working is trickier all around -- both in terms of finding the solution (usually hidden deep in a knowledge base -- sometimes with incomplete instructions), and applying the solution itself. It is disturbing to me to make Registry edits when every Registry screen spells out the certain doom I face in doing so.

While do-it-yourself fixes might be simpler in Linux, a great many people who use computers don't want to fix anything -- at all. It should just work. If it doesn't, dialing tech support for help (or to unleash their wrath and fury) is generally where they find themselves.

Here's the kicker: I've heard many say that because some things didn't quite just work in Linux, they've passed over it for another operating system, with which they also have issues (though not necessarily quite the same), but "there's a phone number to call."

Here's another zinger: At a former life, in the systems department at a library, I found our printing software was having an issue with our lockdown software (both closed source, with paid technical support). For a few days, the solution I was given by the print provider was that we should probably invest in a compatible lockdown software solution -- no recommendations as to what a compatible application might be, even, except that it wasn't one we were using. The lockdown software technical support staff took a few calls before I broke through the "find another print solution" barrier, but after a few weeks, together we got everything to cooperate.

The question arises as to why this is acceptable with computers at all, especially when support is purchased as part of a license or by subscription. Yet it goes on, and I believe a lot of it is a magical thinking scenario -- the idea that a computer is not simply a machine. How many people who call tech support and accept at face value questionable fixes would be onboard with their mechanic telling them that the knocking in their car engine can be solved by turning up their radio?

It's not realistic to expect every person with a computer to hunt down the answers as to why applications, or hardware, aren't working as they should. If they like to look under the hood to discover why themselves, they should be able to -- they shouldn't be required to. They shouldn't have to wrangle with technical support services that send them in an endless loop of finger-pointing and blame. They wouldn't accept it with a broken kitchen appliance, and computers are marginally different in the end.

I could see a viable market opening for independent Linux/open source tech support services. These sorts of services have traditionally fallen on LUGs, but would probably best work as a commercial venture just from the time investment needed to launch and tend to a service such as this. But before this happens, there's a real need for software developers and end-users to come to terms that not everything "just works" every last time -- and this isn't necessarily a failing of the code, the hardware, or a personal bias of the machine against the user.