Why is Microsoft Office so hard to kill?

InfoWorld - It's the question that vexes free open source software advocates and commercial competitors around the globe: Why is Microsoft Office so difficult to dislodge from its perch atop the IT heap? Is it the exclusive bundling deals? The deep Software Assurance entrenchment? Steve Ballmer's backroom deal with the devil?

The answer, of course, is none of the above (though some evidence of a Microsoft-Hell alliance exists). Rather, it's the Office ecosystem -- the vast library of third-party add-ons and vertical solutions built (with copious encouragement from Microsoft) on Office's extensive programmatic model -- that makes Microsoft's suite so hard to kill.

[ Microsoft Office 2010 is looking good. See InfoWorld's first look and a guided tour of Office 2010 highlights. Return to the review of Office alternatives, SoftMaker Office 2008 versus OpenOffice.org 3.1. ]

Consider: A word processor is just a word processor -- until it's mated with a sophisticated macro/template package that transforms it from a generic text editing program into a task-specific custom forms utility. Likewise, a spreadsheet is just a spreadsheet -- until it's linked to a series of complex SQL stored procedures that allow the commodities trader in the next cubicle to perfectly time the market.

Microsoft Office isn't just a productivity suite. It's the world's most widely deployed Rapid Application Development (RAD) platform. Worse still (for would-be competitors), Office is insanely easy to develop for. The Visual Basic for Applications (VBA) language is almost universally understood by Windows developers, and the suite's built-in Macro Recorder makes creating and debugging new projects ridiculously easy. In fact, I wrote much of the OfficeBench test script using code snippets generated by the Macro Recorder in Office 2000. It was a great way to learn the Office object model and remains one of the suite's hidden strengths to this day.

Any attempt to topple Office means declaring war on the army of in-house and third-party ISV developers who have built their livelihoods around the suite's ever-expanding library of automation and integration APIs. So unless you can provide a viable alternative to VBA, OLE Automation, and the rest of the Office programming model, don't expect to make much headway in your quest to dethrone the king. The minions are definitely not on your side.