By Brian Proffitt
Managing Editor
It was kind of nice to see a little community activism on Linux
Today and other media sites this past week. When we posted Eric
Raymond’s open letters to Sun regarding Java, it elicited a
positive and more detailed response from the community in the form
of a contribution to Linux Today from Ganesh
Prasad.
Already, Ganesh’s article is the most read of 2004, and is
likely to keep that status unless a Federal judge dismisses one of
SCO’s lawsuits and thus precipitates the electronic equivalent of
dancing in the streets. Until that day, however, not a lot of
issues are likely to generate this much interest.
Unless, of course, ESR writes another column. Which he did. His
recent rant on the lack of configurability in CUPS struck some
nerves in the community–and this time he was criticized for not
knowing of what he wrote. The issues he raised about CUPS, it
seems, may actually be problems in Fedora, or GNOME, or something
else, depending on who you ask.
I am not going to debate the accuracy ESR’s statements, though I
personally use CUPS on Fedora for a remote printer and I have never
had the problems he’s described. What struck me as the talkbacks
rolled in stating opinions on the article is that ESR may have
accidentally given voice to a completely different weak spot in
Linux and open source in general. If something goes wrong, finding
the solution to fix the problem, or even finding the real cause for
the problem can be a major challenge.
When Raymond saw what he perceived was a problem with CUPS, he
assumed it was a problem in CUPS and broadcast his opinion
about it. But it could have actually been a problem with something
else. The fact that there is no clear idea on what was the cause of
this problem (which, ultimately, leads back to who is responsible
for fixing the problem) is not a very good situation to be in.
Many of us, as geeks, know how to work the system and find
solutions to any problems. We Google, we hit a distro’s site, we
surf SourceForge, we visit JustLinux. We can, if we’re very
knowledgeable, find the actual developer of the application and ask
them for help. And, of course, if we’re really skilled, we can fix
it ourselves and release a patch.
I have done all of these steps, save the latter, because the
only programming I ever did was BASIC on an Apple IIe in high
school. And it was bad. Looking around me, if many of my friends
run into a computer issue on their machines, regardless of
platform, they will contact the software–oh, heck, who am I
kidding? They’ll call me first. Then they might contact
the software maker, search the Web, check the help forums.
This problem of locating where a specific problem is actually
caused is not unique to open source systems, of course. In the
past, I have been told that an application problem was really an
issue with the OS–and then have been told that the same problem is
not due to the operating system, but to the app.
With Linux, though, the problem is more complex. Like the human
body, Linux is a collection of cells that cooperatively work
together in groups and then as a meta-group. And, like the body, it
usually does its job very well. But this kind of differentiated
structure can make identification of problems all that more
complex.
It makes me wonder if there’s a future job market for Linux
diagnosticians–technicians who don’t specialize in any one aspect
of Linux, but who can look at the Linux body as a whole and quickly
diagnose application issues and help find the right solution.
I don’t think this a huge concern, mind you. For the corporate
environment, IT departments should be able to support Linux
workstations and servers just as easily as they do Windows
machines. That’s what they’re there for.
But if Linux is to ever seriously breach the home/consumer
market, there will need to be über-providers of
support that go beyond what the distribution companies cover. Don’t
get me wrong, the distro firms do a fairly good job of support–but
for the non-technical home user, I think there will have to be a
much more robust support system put in place.
For this kind of project, I think Linux can actually succeed
better than its proprietary counterparts, mostly because
of its open-source nature. It could be one-stop shopping for almost
all Linux issues, whether it’s the kernel or the latest version of
Weather Report.
In the proprietary arena, you’re not going to get kind of
comprehensive care very often. If TurboTax breaks, you’re going to
call Intuit, not Microsoft… unless Intuit says it’s Microsoft’s
fault after having you on hold for a half-hour.
Can this work? I know similar attempts have been tried before,
but that was in the dot-boom era, when many people were not
thinking as clearly as they should. With a more cautious, reasoned
approach, I think such a system would be effective and (ideally)
profitable.
Something to think about, if you’re in the entreprenuerial
mood.