GNU/Linux Desktop: The Case Against Running Windows Apps

Does GNU/Linux need to run Windows apps? This question resurfaced last week, when the media noticed that Google has been contributing heavily to the Wine project, which develops a compatibility layer on GNU/Linux for running Windows applications.

Google seems to think so. Not only did Google employees and interns contribute over 1900 patches to WINE in 2006-07, but the company also funded work at Codeweavers to improve the ability of Crossover Linux (a commercial version of Wine) to run recent versions of PhotoShop.

Others are apparently of the same mind. An entire mini-industry exists for those who aren’t yet weaned from their Windows programs. Besides Codeweavers, it includes virtual machines like VMware, emulators like Win4Lin, and — for those who prefer a free software solution — virtualization projects like VirtualBox.

All these solutions are ingenious, and, their technical appeal is obvious. And if coders want to contribute to such projects, nobody has the right or ability to prevent them. However, when financial resources are contributed, I question whether they are being allocated wisely.

Partly, of course, Google was interested in improving Wine for its own purpose — specifically to improve the running of Picasa, which depends on Wine. However, getting PhotoShop up and running seems to have been work performed for no better reason than the fact that a year old survey showed that PhotoShop was the application that people would most like to see ported to GNU/Linux. But, at this stage of the operating system’s development, such investments seem not only unnecessary, but even potentially harmful to the community as a whole, and the arguments in favor of them are seeming increasingly flimsy.

A vanishing need

I admit that, nine years ago, I advocated the ability to run Windows apps as strongly as anyone. As product manager at Stormix Technologies, I made sure that the first version of Storm Linux shipped with versions of both VMware and Win4Lin.

But that was a year before OpenOffice.org. Back then, AbiWord was a glorified text editor, and Netscape was the only available web browser for GNU/Linux. Both Inkscape and Scribus were four years in the future. In general, GNU/Linux desktop apps ranged from non-existent to the minimally functional.

Since then, native desktop apps have started coming into their own. Although more work is needed here and there, productivity software is maturing rapidly for GNU/Linux, to the point where, for most purposes, it equals or exceeds the proprietary Windows equivalents.

A case in point is the GIMP compared to Photoshop. Many people insist that only Photoshop will do for professional design work, and the GIMP is inadequate. Inevitably, though, questioning them reveals that they are either echoing an opinion they have heard, or basing their opinion on a brief look at the GIMP a few years ago. Since they looked with the assumption that free software is necessarily inferior to proprietary, guess what? They failed to investigate closely, and saw the inadequate program that they expected to see.

The truth is, the GIMP is wholly capable of being used by professionals. I know, because I’ve used it for my own design work, and without any inconvenience, either, beyond that of finding where a function was located in the menu. Aside from some obscure filters, the last barrier to using the GIMP was color management, and that was added a few months ago (and not strictly necessary, given that the differences in ink batches always means doing sample printouts anyway).

Much the same is true for all the most common productivity categories. For most users and purposes today, native applications will do the job. Admittedly, users will have to learn the native application’s new menus and keystrokes, but learning the GIMP or OpenOffice.org is no harder than learning Xara Xtreme or WordPerfect Office — or, for that matter, the latest redesign of Microsoft Office.

When people insist that they must have a particular Windows application, they are usually confusing their love of habit with their actual needs. After all, they are hardly being asked to switch from a graphical interface to a switch-heavy command line tool. They are switching to a functionally equivalent program in which some tools have different names or are accessed from different places, and nothing more. Many layout elements, such as the positioning of menus or copy commands are standardized across operating systems anyway.

Since this situation is improving rapidly, getting Windows apps to run on GNU/Linux seems a misplaced priority. It would make more sense to give native apps the final boosts they need than diverting funds into efforts that work against native apps. Probably, it would be cheaper, too. For such reasons, running Windows apps natively is an interim solution whose time is drawing to a close.

Lowering barriers or raising them?

One of the arguments used in defense of such efforts — for instance on the Wine project’s page entitled, “Why Wine is so important” — is that they make migration easier, since users can continue to use the same applications.

However, this argument overlooks the question: why people should switch platforms to use exactly the same applications? This ability didn’t encourage people to switch to OS/2 back in the 1990s, despite settings that made Windows programs run with greater stability than on Windows, and nothing has changed today. If you want to keep running Windows applications, it is less effort to keep using Windows than to go through an operating system installation and learn a new desktop.

Admittedly, GNU/Linux is generally a more secure environment, but those concerned with security rarely make the decision to migrate to a different operating system. Nor does security trump convenience in most people’s decision-making if they are non-technical. Besides, you can get exactly the same advantage by running native applications.

Growing the market too late

Another common argument is that an emulator or compatibility layer can help GNU/Linux break out of a vicious cycle. The operating system, they argue, lacks market share because it lacks applications; at the same time, it lacks applications because it doesn’t have the market share to encourage companies to develop for it.

Aside from the fact that this argument is becoming obsolete, as I already suggested, it is based on at least two fallacies. First, it assumes that, if a GNU/Linux market is created, companies will develop for it. But why should they, if a project like Wine has already done the work for them? If the Windows version runs decently on a free operating system, why would a company waste resources on developing a native version?

Even more importantly, software vendors like Adobe are proverbially suspicious of the GNU/Linux model. While they are willing to provide free players that encourage the use of their other products, such as Acrobat and Flash, many vendors remain convinced that no one using the platform will pay for a commercial app — despite the example of Oracle, or high-end software like Maya or Houdini. With this mindset, most vendors will probably need a large market share before they would even consider developing native versions.

What’s more, at this point, this assumption has become a self-fulfilling prophecy. In the absence of commercial applications, the GNU/Linux community has developed its own solutions. Ten years ago, the release of a native version of QuarkXPress would have been greeted in many circles with yelps of glee. Now, GNU/Linux users interested in desktop publishing are using Scribus, and many would greet a native version of QuarkXpress with massive yawns. The desktop vendors had their chance to develop for the platform, and have already lost it through their own timidity.

Other priorities

However, the most telling argument against running Windows apps is that they are proprietary. While many users reluctantly use proprietary tools when free ones don’t exist, few actually want to encourage the practice. For many users, GNU/Linux isn’t just an operating system. It’s also an alternative way of interacting with computers and the Internet — a statement in favor of free speech and consumer rights. No matter how necessary proprietary apps may sometimes be, doing so is a stopgap measure, not an end in itself, and many do not want to encourage it. In fact, a sizable number of users seem willing to use free software even if it is mildly inferior to proprietary equivalents. To such an audience, running Windows programs is an option that holds little appeal.

Google doesn’t take second place to anyone in its support of free software. Its Summer of Code alone, to say nothing of the other projects and conferences it has sponsored, makes that clear. But in this one instance, its contribution needs to be reconsidered.

If Google or any other company wants to accelerate the use of GNU/Linux, then a better approach might be to fund one of the Free Software Foundation’s high-priority projects. These are projects that working to fill the actual gaps on the free desktop, and they are truer to the spirit with which the operating system was developed in the first place. They deserve support far more than any effort to run increasingly redundant Windows programs.