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 meand 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 versionsso 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 problemand 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 usingthereby 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 strategiesand 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.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.