Compatibility Has Many Meanings

Whether we're talking about a single city in New Hampshire, or about three major Asian powers, the notion of having a "Microsoft exit strategy" seems to be spreading almost as fast as the SoBig worm.

Whether were talking about a single city in New Hampshire, or about three major Asian powers, the notion of having a "Microsoft exit strategy" seems to be spreading almost as fast as the SoBig worm. Customers are increasingly taking the measure of both the direct costs of software upgrades, especially the "Longhorn surprise" that might push the next major Windows upgrade beyond the term of current maintenance agreements, and also the indirect costs of either installing frequent patches or living with the consequences of neglect. And having measured those costs, those customers are looking for alternatives.

Security-centric problems, in particular, are spiraling out of control as the network becomes more hospitable to the rapid spread of malicious code, thanks to increasing use of mobile devices whose connections lack adequate protection and also to the growing use of broadband connections by unsophisticated users. Its not a question of whether alternative platforms are more secure, but of whether their problems are more swiftly characterized and fixed.

I was struck, though, in the article on the Asian platform initiative to which I referred above, by a comment from a Japanese trade ministry official who referred to developing "software that is not Windows compatible." For some reason, that phrase seemed odd to me—and then I realized why. Its because I dont allow myself to depend on any software that only runs on Windows, but neither would I depend on software that defies that platforms dominance. I try to use data formats that are not application-specific, or in the alternative to use only applications that can work with their own data formats on any of several supported platforms: on any given day, I truly dont care whether I have a Windows machine within reach as long as I have something with an Internet connection. But if that something turns out to be a Windows machine, thats fine: My point is that it should not matter.

Yes, I do use several Microsoft applications, principally Word, Excel and PowerPoint--but I use them both on Windows and on Macintosh OS X, and on Windows I move interchangeably between the Office 97, 2000 and XP versions of those applications depending on which machine Im using that day. I therefore avoid all application features not common to all versions—so I guess Im really a common-subset user of the .DOC, .XLS and .PPT file formats rather than a traveler on the Office upgrade path. If someone receiving a document from me is using StarOffice, theyll probably have no problem—and if they do, I wont object to being told, and Ill make a real effort to avoid that incompatibility thereafter.

Im not sure if I count as an Outlook user, since most of the time Im in the Web client rather than running the fat client application. For those of you whove been yelling at your screen, "What about all the custom applications that I need to write for my company?", my answer is: Why would you deploy anything in other than Web-client form? Almost every development tool now makes that a convenient option.

When you do write your Web-client applications, Id take it as a favor if youd remember that my default browser is Mozilla, and that I have IE installed on my various machines only because too many sites dont work with anything else. If your e-business site demands that I fire up a browser that I neither like nor trust, you can expect me to look for other providers of whatever Im getting from you--and Id think that national governments would be quick to say the same, with even more likelihood that people will listen.

I also use Wolfram Research Inc.s Mathematica 5 and Waterloo Maple Inc.s Maple 9 for math and other analytic tasks, Adobes PhotoShop Elements for image processing, and Adobe Reader for reviewing documents from many sources. All of these applications have their own complex data file formats, but some of those formats are fully disclosed; all of the products run on multiple operating systems. Adobe Reader even runs on my PDA. And in all of these cases, I use non-proprietary file formats whenever possible: JPG, TIFF, BMP and PNG for my images, for example, rather than PhotoShop format. I also try to save and mail my document files in open formats, such as RTF, whenever I dont know what the recipients are using—thereby also gaining protection against the "undocumented features" of more complex and proprietary formats, such as .DOC, in which new security flaws (such as vulnerability to malicious macro execution) continue to come to light.

Id urge Japans trade minister, therefore, as well as those involved in any entitys drive for platform independence, not to use phrases such as "not Windows compatible," but rather to focus on data-portability strategies—and to choose their purchased applications from the more than adequate list of products serving multiplatform communities. Id urge them to build their custom development teams and outsourced custom development efforts around multiplatform APIs, like those of J2EE, and to establish service-provider partnerships with companies like IBM and Hewlett-Packard that vie for the title of worlds largest supporter of open-source systems.

I dont know what it means to be "not Windows compatible," but it sounds about as useful as being "not gasoline compatible" for a transportation device or "not 117-volt AC compatible" for a home appliance. With the right approach, IT efforts can avoid wasteful confrontation of any single vendors or technologys limitations: Its much better, if I may say so, to rise above them.

Tell me about your compatibility goals.