Whining about Wine, crossing off CrossOver Office

Last week, after playing with Wine, I concluded that free software support was just as good as support provided by a commercial vendor. This week, after trying a commercial alternative to Wine, I see an area where the open source community can clearly improve. CodeWeavers’ CrossOver Office beats Wine hands-down when it comes to a polished installation procedure that just works. But the more I played with CrossOver Office, the more it began to look like the same juice in a fancier bottle.

I had a long row to hoe to get Wine installed, as I discussed last week. By contrast, to install CrossOver Office, I downloaded a shell script, executed it, and in short order had a working application in my start menu. CrossOver Office added two new entries to my KDE start menu: one for CrossOver, with choices for documentation and setup, and one for Windows Applications, which would hold … well, you figure it out.

CrossOver Office handled application installation just as well as it installed itself. I popped the installation disc for Photoshop 5.5 into my computer’s CD drive and clicked Install in the CrossOver Office Setup application. Just as it would have under Windows, the automatic installation began and ran, and before you could say “humbled by the developments of the last few weeks” I had Photoshop running on a Linux laptop. It was a bit surreal seeing a Windows installation procedure run under Linux.

This is where the commercial product trumps the open source version — the work on polish and ease of use makes the program far more suitable for commercial use and helps justify its $55 pricetag.

CrossOver Office may be more polished than Wine when it comes to installation and user interface, but it has its limitations. CrossOver Office supports a very short roster of products; a few Microsoft Office applications, Notes R5, and Quicken 2002. That doesn’t mean that all other applications will fail to run under CrossOver Office; you might luck out. CodeWeavers provides a nice graphical user interface for installing both supported and unsupported programs.

To test the program’s ability to run unsupported programs, I picked a couple of CDs from my bookshelf. I started with Macromedia Dreamweaver MX. It failed to install, and I saw it listed on CodeWeavers’ Known Not to Work list, though others appear to have had success. Next I tried installing Lego Technic CyberMaster, a 1998-vintage kids’ program for building robots. (Yes, it’s robot month at NewsForge.) The program installed fine but failed to run. A Google search turned up the error message the program displayed and a possible fix, which required modifying a Windows registry key. CrossOver Office has its own version of the registry, but when I tried to use CrossOver Office’s regedit command to modify it, I got a long list of error messages, and as there was only so far I was willing to go for this little test, I didn’t pursue the problem further.

This whole exercise in Wine and CrossOver Office left me a bit
dispirited. Neither product is really an adequate avenue for running
a wide range of Windows programs under Linux. CrossOver Office is
more polished than Wine, but it’s guaranteed to work mostly with
Office applications for which StarOffice
and OpenOffice provide
similar functionality. If you truly need to run Windows applications
on your Linux box, try VMware
Workstation or Netraverse’s Win4Lin. At $299 and $89 respectively, they’re a lot more expensive than the alternatives,
but that just demonstrates that with free software, there’s no free
lunch.

Free software support? Works for me

What do you do when you have a problem with proprietary software? Go to the vendor. What do you do when you have a problem with open source software? Take it to the streets. And — surprise! — the word on the street is just as good as the word from on high.

For instance: This week I was trying to install Wine as part of a larger project. I downloaded the RPM file for my SuSE system, but I was unable to install it because of failed dependencies. I noodled around with commands on my system trying to find what I needed, but without success. Where to turn?

Support step one: Look on the Internet. I did Google searches against both Web sites and Usenet newsgroup archives. The key here is using relevant search terms. I was able to find messages that pointed me toward packages I needed to install to resolve most of the dependency problems.

Unfortunately, I had one nagging problem I couldn’t solve, and it only takes one to prevent the installation from going forward. It seemed as if no one had had quite the same problem I did. So it was on to …

Support step two: Post to Usenet. I found an appropriate newsgroup, comp.emulators.ms-windows.wine, home for Wine discussions, and posted a message detailing my problem. Then I waited. And waited. (Maybe time doesn’t pass more slowly when you need technical support, but it sure seems like it.) By the next morning my question had gotten no response. It’s hard to tell whether that’s because the newsgroup doesn’t get much traffic or because the question was a stumper, but either reason looks the same when your fingernails are bloody stumps.

Support step three: Join a mailing list. Frequented by users with interest in and experience with specific applications, mailing lists and online discussion forums can be a font of knowledge. I visited Wine HQ and discovered several mailing lists users can take advantage of. I signed up for one and asked my question. Twenty minutes later I had my first response. Within an hour I had the solution I needed. Thank you, Thomas Chiverton and Ivan Leo Murray-Smith.

Oh, the problem? Though I had downloaded the latest version of Wine for SuSE Linux, it was an RPM designed for version 7.2, not 8.2. Should the package name, wine-20030813-SL7.2.i386.rpm, have been a tip-off for me? Probably. I’ve already sent myself into a corner to think about what I did.

The point, however, is that I was able to get answers from a variety of sources, including an answer that solved my problem, fairly quickly and without financial cost.

Now let’s contrast that with support from a proprietary software vendor. Telephone support is available from many vendors, but most of them charge for it, because phone support requires the employment and training of live human beings, and human resources are costly resources. I’ve had mixed luck with telephone support — some reps really know what they’re doing, while other just bring up scripts on their computers and walk you through them. In those cases, I don’t know why the vendors don’t just put the scripts up on a Web site.

Many vendors provide online knowledge bases you can search on their sites, and which are often accessible via Google searches as well. I appreciate any vendor who makes such information available; often, they have just what I need in their archives.

Most vendors also provide online support forums staffed by employees. These tend to have good information, but I haven’t always gotten my answers very quickly, and generally only after a “conversation” of multiple posts over several days.

And proprietary vendors are known to make use of Usenet as well. Microsoft and Symantec, for instance, have large numbers of newsgroups for their large numbers of products. Both company support staff and other users can help those with problems.

So which is better — relying on the kindness of strangers or depending on the company that developed the software you’re using? My intuition tells me the latter, because companies have a vested interest in keeping customers happy, but my experience shows me very little difference. I’ve had excellent luck finding answers to most of my free software source support questions from Google Groups. In cases like this week’s that require more help, the open source community steps forward with the right assistance.

Many organizations are concerned about adopting free and open source software because it often lacks a dedicated support staff. In my experience, lack of support is not an issue.