When I pulled out my garden hose at the end of the winter, I found it was kinky and cracked, and let little sprays of water shoot out in odd places. ("Like its owner," my wife says.) It still did its job, mostly, but I can't say I'm really happy with it. Which brings us to application software. I've been trying a number of programs lately that allow clients to communicate with each other, and I've been tearing my hair out trying to use them.
For instance, take Kssh -- a KDE front end for Secure Shell. Granted it's not yet a version 1.0 product, but version 0.6 completely fails to run under Mandrake 9.1 for me. When I visit the application's home page for troubleshooting information, I find, in full, "I have no time to write anything about kssh." This should be unacceptable -- one should never release software without documenting it, and that's especially true of software that's still under development, when feedback is especially valuable. If the primary developer on an open source project has this attitude, he should pass the project on to someone with more enthusiasm and professionalism.
Sometimes it isn't just the documentation that's at fault. My boss pointed out what seemed like an interested application -- Unison is designed to synchronize files in local directories or on two machines over the network, running over an FTP or SSH transport. You can run it in command-line or graphical mode on Linux and Windows. Since I use a GUI on both systems, I opted to use Unison's GUI.
Unison lets you create profiles that specify the two machines and directories you want to synchronize. The interface is very simple. Unfortunately, it's so simple it leaves off a means to modify an existing profile, or delete profiles you no longer want. Mistakes being a natural part of my life, that leaves me with a long list of profiles among which only one or two mean anything.
When I was learning to program (an endeavor I later practiced professionally for eight years), I remember my professor admonishing the class, referring to data structures, "Never create something you cannot destroy." Alas, poor Unison users are stuck with profiles the developers won't let them destroy. And the simple interface fails to include any online help, although there is copious documentation on Unison's Web site.
While I'm whining, let me express my frustration with Mandrake's treatment of non-bundled RPMs. I download an RPM and click on it, which brings up Mandrake's RpmDrake software installer. If the operating system knows enough to start up RpmDrake, why doesn't RpmDrake know enough to install the program it was invoked with? Instead, RpmDrake makes me search its database for a package, which it fails to find among its internal list, because after all, if it had been available, I wouldn't have had to download it! Luckily running
rpm -i in a console window seems to do the trick most of the time.
I don't mean to single out Mandrake. I've been irritated with SuSE too. I tried to install Opera under SuSE 8.2. I love Opera. But SuSE's YAST2 administration program tells me "libXm.so.2 is not available." A Web search confirms this is a known problem, and explains how to work around it. But this is downloaded software, not something I have to install from a CD-ROM, so if the problem is known, why not just fix it?
Nor are the problems limited to Linux. I installed Internet Information Server's SSH service on a Windows XP Professional client. It's running, but its management application hangs whenever I try to use it. Connections to the service regularly fail, and without the management console I can't figure out why.
If I, as an experienced, intelligent (and humble) user, can't get past these issues, the average computer user hasn't a chance. Without a big marketing budget, open source software can be successful in the mass market only if it is at least as easy to use as commercial software. Making things easy on users is just as noble as providing useful core capabilities.
Meanwhile, does anybody have a good file synchronization application for me? Or a new hose?