A couple of weeks ago I asked people to help me find a fair basis for a comparison between Microsoft Office and OpenOffice - and got 230 or so responses.
There are some interesting themes in there. There's a large group, for example, who think some older packages, particular those from WordPerfect, were, or are, better for at least some functions.
That doesn't help me compare the two big suites today, but it was interesting enough that I brought up Wordperfect 7 for CDE on Solaris 2.5.1 on a Solaris 10 machine running Gnome to see if things still worked - and they do: WP 7.0 wouldn't read current MS or OO files, but V4.2 PC-DOS files could be opened, saved as Word 6.0 or Frame 4.0 (MIF) files, and then opened with the current tools.
Overall, however, the comments that led to a change in my thinking looked like this one by "ForrestC":
VBAI've played with Open Office a bit, but it doesn't do what we need at work, and I refuse to run the Java runtime on my home machine, so right off the bat MSFT wins here.
Office does about 80 % of what we need at work. It more or less supports common business tasks; it just doesn't tailor the way it does them to the way we do business.
VBA is far from the "best" or "ultimate" programming environment, but if you give your project a little thought, you can still write a bunch of lower-level functions that do what needs to be done, and high-level helper functions that coordinate the task at hand. Then you have a 'script' that can be edited without recompiling a huge amount of C code.
VBA + OLE Automation let you do things with Access, Excel, and Powerpoint that are like mail merges, but a lot more useful in a business sense. For extra points, you can use .NET interop.
The fact that Office apps work together so well, and all of them support a very similar ( and pretty damn easy ) programming model, plus the fact that you can have a complete ( Front End + Back End ) database solution in Access that will fit in an email and not require a $50 K/yr DBA ... these things are missing from your somewhat one-sided comparison.
I believe this post nicely illustrates why Microsoft Office often wins decisions over OpenOffice or StarOffice - and thereby suggests a way to dethrone it as the default organizational choice.
To see that, look closely at what this Microsoft Office Vs. OpenOffice decision maker, or influencer, actually says and then think about what that tells us about how a decision like his gets made. Look at his concept of the office and it's clear he sees organizational IT as a simple sum of stand-alone desktop IT: "use of Access avoids the need for a $50K DBA;" he imposes his biases on what he reads, finding a "somewhat one-sided comparison" in a blog that doesn't contain one, and his view of scripting is entirely conditioned by BASIC: " write a bunch of lower-level functions that do what needs to be done... [to produce] ... a 'script' that can be edited without recompiling a huge amount of C code."
And yet I think this is a very lucid and well thought through comment zeroing in directly on the one thing that matters most: the fact that the Microsoft Windows ecosystem lets him, and others like him, tailor documents and document flows to business processes.
In my first draft for this blog I wrote the next paragraph as "There's a better way to do this" - and now I'm going to try to explain the basis for that judgement in tomorrow's blog. Meanwhile, lets just say there's another way to do this.
In a large organization you could for example set things up so all documents, whether newly created internally or arriving from outside, are stored using a long lasting open format and then combined and formatted on demand for use.
Imagine, for example, a state government with six thousand employees in 30 agencies or departments and all the usual document creation, distribution, retention, and consistency problems. In response we'll pretend to set up a hub and spoke server system with desktops getting their documents from local servers, all acting as front ends to a central repository.
Although there are other choices, I'd use Apache Cocoon with PostGres for this simply because I've used it before.
With Cocoon incoming documents can be converted to an open document format for storage and reformatted on demand for use with everything from word processors to CAD/CAM packages. More importantly: database and application integration is straight forward with insertions/retrievals done on document request; retention, destruction, security classification, and other policies are centrally implemented and enforced; and enterprise applications can generate documents in one standard, text based, form that can be transformed, on the fly, for use with any of the major desktop applications.
You could, for example, capture the ready to print bills produced by something like a third party billing system for which you don't have the source, reformat them for open format storage, and then serve them up in Excel, Word, OO, PDF, or plain text form as requested by the users.
Similarly tax notices stored as XML text could be sent to the taxpayer in their entirity while appropriately redacted versions are automatically placed on a public web site.
I'm not aware of anything that you can do within the Microsoft ecosystem that you can't do at least as well, but more reliabily and for a lot less per document, using Cocoon. Want a forced retention policy? that's trivial; want a document only people on an approved list can read? no sweat; want to ensure that five different agencies report the same numbers? duh; want to produce reports integrating multi-agency results? get them to agree on a format, and you're done; want to massage raw ticketing statistics in Excel? you may need your head examined, but the technology will let you do it easily enough.
You'll have noticed that in doing this we've said nothing explicit about the desktop. Microsoft Office will work as well as ever, so will OpenOffice, Koffice, or StarOffice. What Cocoon does in this context is remove the ecosystem supporting Microsoft Office, thus putting the two suites on an equal footing in terms of what they'll do for the desktop user.
Bottom line: you sell Cocoon on the basis of a common, open, document format coupled with high volume repeatability, low cost programming for downstream document integration and related management tasks, and strong document controls.
Do you know how to find the last aligator in a swamp? Right: first drain the swamp, then clear out all the dead aligators. In this case, with Cocoon in place, the desktop Office Office suite question can be resolved on a cost/performance basis - and that's a no brainer.