It's easier to re purpose MSOffice for the Web rather than try to replace it. For consumers, replacing MSOffice is easy. For businesses and organizations that depend on MSOffice bound business processes, rip out and replace is impossibly difficult, disruptive and costly.
Microsoft owns the client in "client/server". They seek to own both the client and the Web-Stack in the emerging "client/Web-Stack/server" model. For Microsoft, this means controlling the transition of MSOffice bound business processes from the desktop to the Web-Stack.
To pull this off, Microsoft had to garner control of the formats and protocols future web enabled business processes would depend on. MSOffice does not produce clean, standards clompliant W3C HTML, XHTML, CSS, XForms, SVG, SWF, PDF or RDF. And it never will if Microsoft has their way.
Instead, Microsoft has provided these transitioning business processes with a complete set of proprietary dependencies based on ISO approval of MSOffice-OOXML and a conversion component to the proprietary XAML "fixed/flow".
XAML is of course part of the proprietary Windows Presentation Foundation layer set of technologies. Other aspects of WPF include Silverlight, Smart Tags and LINQ. All proprietary.
The Microsoft "Web-Stack" is based on the Exchange/SharePoint/SQL Server core, which has in recent years become an unstoppable juggernaut - rolling OSS and proprietary alternatives alike. The success of the MS Web-Stack is based on one simple advantage: superior integration and interop with the MSOffice-Outlook desktop "cliient".
I would argue that MSOffice can be re purposed using the developer plug-in model provided for MSOffice, and, reverse engineering the relevant MSOffice-Outlook <> Exchange/SharePoint connecting protocols. Using the plug-in model, we are able to to produce standards compliant open web formats. Using the reverse engineering approach, we can tap and redirect connectivity channels and collaborative computing features.
Nick Carr waxes eloquent on the potential of Google Office alternatives. So far Google has been unable to lay a glove on the MSOffice business processes, enabling MS the time to get their ducks in order. ISO approval of MSOffice-OOXML establishes MSOffice as a standards compliant web editor. The December MSOffice SDK beta featured a slick and easy to implement OOXML <> XAML converter. And the MS Web-Stack juggernaut is rolling up businesses like nobodies business. The great transition is just beginning because finally, Microsoft is ready to put the desktop into play.
If Microsoft succeeds, we run the risk of breaking the web into two sides; the consumer web and the business web. Each side will have it's own formats, protocols and API's. since the consumer web will be based on open standards, it will be easy for Microsoft to coopt what they please, and disrupt where they see a challenge. The "business web" however will be based on MS WPF-.NET proprietary formats, protocols and API's. This web will be outside the reach of anyone but MS licensed and approved partners.
The problem Google faces is they will most likely be relegated to the consuemr web, while Microsoft will be in position to provide a converged platform for consuemr-business systems. Meaning, MS will threaten Google far more than Google will ever be able to threaten MS. Unless of course some smart guy figures out how to re purpose MSOffice before the juggernaut reaches critical mass.
~ge~