Selling against Office 2003

"Noster fungitur"; Ours works. It's the motto I suggested to a local Mac Users group, but it's also the theme you need to push when selling Open source against the Microsoft desktop system - Windows 2003 Server with Office 2003.

Office 2003, in combination with Server 2003, is the first major Microsoft product to incorporate their vision for an XML enabled future filled with hot button features like end to end document management.

XML started out as a subset of the SGML (structured general markup language) developed for the printing and text processing industries. In use XML requires a marked up document, a document type definition (DTD) like HTML describing the markup used, and a processor capable of formatting the document according to its embedded markup.

Most web browsers have the information needed to process the HTML DTD compiled in, but it doesn't have to be this way. The more general approach is to have the formatter first read in a mapping file that relates tags to output formats and then read in documents containing those tags for processing according to the definitions in the mapping file. With this approach any group cohesive enough to act on shared documentation needs can define its own DTD and rely on generalized XML tools to correctly format documents marked up according to that private DTD.

Document markup languages produced in this way are fundamentally passive. The XML definition governing the creation and use of such DTDs envisages an independent formatter to process the markup instructions and produce the formatted output. Notice that the formatter - which could as easily be a medieval monk working with pressed gold leaf as a modern knowledge worker using Quark on a Mac- doesn't change the content of the document. In other words, markup doesn't affect document portability because you can always strip out the embedded markup to fully recover the document's content even if you can't exactly reproduce the intended format.

When Microsoft decided to embrace XML it promptly extended this model to include a wide range of active functions that do affect content. A Microsoft XML document can, for example, call Active-X components, interact with a DLL, or pass tagged content to a VB script. As a result you can use Microsoft XML tools to do things like make documents that automatically update themselves, documents that refuse to be emailed to people not on a predefined list, or documents that delete their own contents if called up after some pre-specified date.

This, of course, is no longer XML; it's more like an embedded RPC capability that turns the Office document into a client for server based processes. As a result it has both traditional RPC weaknesses: fraud detection can be difficult if not impossible and, of course, local operation is dependent on the availability of the remote server.

In theory, for example, a secured document couriered to you on a write once CD could be subverted to his own purposes by a bad guy able to spoof the remote server. In practice this kind of attack should be very rare, but a lot of people can expect to find documents legitimately emailed to them rendered unreadable by nothing more threatening than a routine server upgrade at the sender's site.

Implicit in this is the ability to control both the use and the content of a document long after someone else receives it. For example, documents could refuse to display themselves on PCs which fail to meet hardware identification or software licensing checks and, of course, the same document can show different content to different people or at different times.

The threat to open source, therefore, is that the Microsoft XML enabled document will represent the ultimate in viral marketing - spreading Microsoft Desktop System (Server plus Office) licenses wherever they land because the people who get them from clients or suppliers will have no option except to license the same Microsoft products. Certainly a Microsoft XML enabled document opened using OpenOffice.org won't function as an interface to data stored on a remote Microsoft Server - and users won't able to create or modify those documents using a local Linux server running Samba either.

As a group, people who use MS Office are generally willing participants in this kind of viral marketing. To them, the fact that their use of the product forces their clients and suppliers to use it just confirms the rightness of their own decisions and it's open source bigots like me who are making trouble and trying to impose our opinions on them.

Get them to understand, however, that when a document becomes an application interface rather than a thing that's complete in itself, it loses its value as a record of information received and their attitudes may change a bit.

Most of the time, what'll happen is that they'll become vaguely aware that their attitude is putting their organization at risk and express the resulting internal discomfort through a rationalization by telling you that they have no alternative. Once they do that, however, they're your sale to lose because there are better open source alternatives that already work to meet the same needs.

For example, the Cocoon project and its various spin-offs and competitors offer a better way to meet the needs addressed by Microsoft's promised document management capabilities. The Security Assertion Markup Language (SAML) and other XML work spun out of the Liberty Alliance offers a complete, functional, framework for document authentication, user identification, and access authorization that can be used without hardware or software lock-in. These products work now - people who want to use them can do so without waiting for Microsoft's longhorn OS, without waiting for Palladium and hardware identification, and without participating in the usual Microsoft debugging processes. Remember: "Noster fungitur"; ours works. Now.

Positive alternatives like this do not, of course, address the negative side of the problem: your customer can adopt Cocoon on Linux today to achieve most of the goals Microsoft has set for its RPC/XML extensions but what does he do when his customers send him Microsoft XML documents?

The answer to that is a format gateway. These don't exist yet, but its easy to see how they could be built and used -meaning that they can be expected to spring up as demand for them materializes. In firewall mode a format gateway would run incoming MS XML documents once to freeze and date stamp their contents before translating them to Openoffice.org formats and forwarding them to the intended recipient. Similarly, the gateway would reverse the transformation on the way out, automatically handling any needed cryptographic functions and third party server calls in both directions.

In web server mode -like the TOM document conversion server at CMU- format gateways would accept documents in one format and forward or return them in the alternative format -except that Microsoft Office formats would not be forwarded to addresses inside the organization.

Format gateways would let organizations with thousands of users participate in Microsoft document exchanges while licensing only a small rack of Microsoft servers at the gateway and minimizing both costs and risks through use of open source products internally.

Put these pieces together and what open source offers is a better option you can sell using a classic push/pull argument. On the pull side, just cite the fact that the open source solution works now, costs less, and doesn't produce either lock-in or guaranteed document obsolescence. On the push side, just get the customer to think about security and the precedent Word's file system revision history means in terms of the likelihood of having to port all his office documents each time Microsoft changes the backend server processes.