« Garage-Gate 2007 | Main | Microsoft Modus Gets Smoked in Nigeria »

Comments

Petem

im just curious.. just when did you find out that ODF was not about that which you mentioned.. (see below)

Those market requirements are...

* Compatibility with existing MS documents
* Interoperability with existing MS applications
* Grand convergence of desktop, server, device & web systems


at least for the first 2.. it was about as clear as clear could be from the very beginning to, i want to say 99.97 percent ..the 3 percent would be you 3..
that ODF was not meant to be compatible/interoperable with OOXML or any MS document like you speak of.. it was not meant to implement any of the MS mistakes.. that is WHY.. MS has chosen among other things to promote their OWN format... i thought that would have been obvious.. im still not clear why you do not just support OOXML.. it is a MS format and im sure is meant to cover ALL 3 of your requirements.. yet.. you choose to go and promote yet a third format/standard/framework or what have you..... would you then abandon CDF for something else if the W3C does not like your ideas or if you find out 6 months from now.. that OOPS.. CDF is not what we thought either..

Timothy

The requirements for interoperability are simple - we must have an open standard that is supported by many vendors who compete based on merit. "Compatability" with existing MS documents is not and should not be a goal for these standards. If data represented in any form cannot be properly converted to a standard format then it is clear that this data cannot be accurately interpreted at all. Simply shoving old ways of expressing things in to new standards is not going to make them comprehensible to other vendors' products.

With this recent campaign you have done more damage to the open standards effort than any good you may have done supporting ODF. By repeating Microsoft's spiel on the need for 'compatible' formats you bolster support for OOXML. The fact that the "OpenDocument Foundation" is doing this is no less than a betrayal of all those who donated to your cause.

Email Person

You may have missed this bit:

"The one thing I'd really want your readers to know is that CDF (even together with WICD) was not created to be, and isn't suitable for use, as an office format. "

That was from W3C. So, it looks to me like CDF doesn't address your goals. It's not an office format and thus not compatible nore interoperable with MS office documents.

J David Eisenberg

+1 for "Email Person"'s comment. I fail utterly to see how CDF is compatible with existing MS documents.

Insubstantial

They paid you off, didn't they?

Wesley Parish

Well, FWIW, I've been staying out of the arguments, recriminations, etc, over the Open Document Foundation, ODF, CDF and goodness-knows-what-next ... What I'd like to know is if you passed on my email about YFilter to Gary Edwards? I've found what appears to be another message broker - which is the technical name for the workgroup/workflow backend that he discusses - only this time it's a NASA Open Source project called POUR, and there's also ECHO; you might like to look at Berkeley's CONTROL and some related projects. I'm not interested in jumping into political battles unless I know precisely what I'm jumping into; but if you turn any - or all - of these into a full workgroup/workflow backend, please keep it open source.

Gary Edwards

Market Requirements
We've known of these market requirements since June 19th, 2006 when we first met with Massachusetts CIO Louis Gutierrez and his ITD staff. They are the result of a year long pilot study involving the implementation of ODF.

The pilot study failure to implement ODF using desktop alternatives to MSOffice lead to the May 2006 RFi, Request for Information concerning the feasibility of an ODF plug-in for MSOffice. The first two of the market requirements deal with the ODF plug-in challenge of working inside MSOffice bound business processes and accessibility add-on restrictions. The third requirement, that of grand convergence, addresses what Massachusetts needed to do with these portable XML documents.

The end game is that of neutralizing and re purposing MSOffice without disrupting or having to re write existing bound business processes. Once this is done, th ekey becomes the migration of those existign bound business processes to open source Exchange/SharePoint alternatives, where they would be re written to take advantage of collaborative grand convergence.

Once the business processes have been successfully migrated to open source hub alternatives, it's rather easy to start replacing MSOffice on the desktop with ODF ready alternatives.

The key to understanding this is to NOT focus on the proprietary file format barrier, but instead, focus at what this barrier is protecting - the MSOffice bound business process.

We continue to believe that the way you crack an MSOffice bound workgroup is to fight them at the Exchange/SharePoint Hub. The ODF plug-in alone is not able to do this. The only thing the ODF plug-in can do is neutralize MSOffice and set the stage for a non disruptive re purposing.

We could see that Microsoft was effectively using the MS-OOXML Compatibility Pack plug-in to perfect a non disruptive business process migration to the Exchange/SharePoint Hub. Our approach to this problem was to simply clone the entire MS migration strategy, and compete against it with an ODF plug-in - open source hub alternative.

To pull this off though, we needed a version of ODF able to meet those first two requirements.

~ge~

Gary Edwards

You're right in that MS-OOXML is designed to meet the three market requirements, and ODF is not. The fact that Microsoft has put into play a monopoly base of 550 million MSOffice desktops with this business process migration to Exchange/SharePoint is a rare opportunity to free those desktops. The opportunities that open up in this scenario are as exciting as they are important to end users. Many desire competitive alternatives and innovative collaborative computing solutions that return sovereignty over information and information processes to the rightful owners.

Of course we would abandon CDF if it didn't work. Once the MSOffice business processes are successfully re written to the Exchange/SharePoint hub, the full reach of the emerging MS Stack of desktop, server, device and web systems kicks in with a long term lock-in impact unlikely to be challenged in any meaningful way. Anti trust or otherwise. The cost to end user of trying to reign in Microsoft will prove to be far too prohibitive to enforce. And we'll have to live with these consequences where Microsoft determines who plays, and who doesn't.

Bear in mind that the moment your focus turns to the MSOffice - MSOOXML - Exchange/SharePoint juggernaut, this becomes a web platform challenge. The file format is just a portable information container expected to service business processes that are increasingly web centric and collaborative in nature. Whether the portable document container is MS-OOXML, ODF, or CDF, the requirements have changed from desktop only to the grand convergence of desktop, server, device and web.

~ge~

Gary Edwards

Interoperability Requirements

If you're going to design a single file format acceptable to the market, i don't see how you could possibly ignore 550 million MSOffice bound desktops?

How is it that they, the great herd of 550, are to convert their existing MSOffice documents, applications and processes to ODF if ODF is not designed to accommodate that purpose?

The MS-OOXML Compatibility Pack plug-in makes it very easy for the 550 to convert their existing documents, applications, and processes to MS-OOXML, Exchange/SharePoint and the emerging MS Stack web platform challenger.

Is it really a good idea to not provide them with an alternative choice? To simply blow them off?

~ge~

Gary Edwards

Is CDF a possible alternative to MS-OOXML?

I think so. But now that IBM, the W3C, and the OASIS lawyer have declared that it is not, one has to wonder. They are the experts. They must know.

That doesn't in any way lesson the need to find an effective alternative to MS-OOXML. An alternative able to meet the basic market requirements, and, able to open up open source competition with the Exchange/SharePoint juggernaut.

Exchange/SharePoint enjoys an incredible advantage over all competitors. The E/S Hub is integrated into existing MSOffice business processes at the MS-OOXML file format level. If Zimbra or Alfresco had that same level of integrated access, they could compete and triumph against the E/S Hub. Today they fight on, but it's not a level playing field.

This goes to the heart of the full interoperability versus limited interoperability arguments that we all hoped open standards would settle. But if Microsoft is not going to cooperate at the standards level, should we just give up?

The only way to beat Microsoft is take them on in the real world trenches where this business process migration in now taking place. Sure it's not fair. Microsoft is holding all the aces. But giving up is not the solution. Nor is whining endlessly about how unfair and ruthless a predator Microsoft truly is.

By the time the standards world gets around to dealing with this it will be too late. Defacto monopolist market standards with business process level bindings, will greatly diminish the relevance of open standards setting organizations such as ISO. Try re establishing that once the damage is done.

~ge~

Gary Edwards

J David

They didn't pay us off. No one paid us off. Nor is there any transfer in kind or promissory offers. There isn't even a conversation suggesting such a thing. There isn't a conversation of any kind. In fact, you probably have a better relationship with Microsoft and/or Microsoft proxies than i ever will.

It's real simple. If you want to understand the da Vinci group, understand the problem we are trying to solve. We were asked to solve an implementation problem in Massachusetts that proved to be very difficult, no matter what XML file format is involved. If anyone wants to understand us, all they need do is focus on the problem set defined by the Massachusetts market requirements.

... Compatibility with existing Microsoft documents

... Interoperability with existing Microsoft Office applications

... (Cloud ready) Portable across the grand convergence of desktop, server, device and web systems

The mistake however that everyone seems to make is to think of the Massachusetts problem as a file format problem. It's not. It's a MSOffice bound workgroup - business process problem. The binary file format is just a barrier protecting the real problem of bound business processes.

The da Vinci plug-in is a clone of the MS-OOXML Compatibility Pack plug-in, meant to address the exact same issues. Yes, at first we only saw the file format conversion. But as we came to understand the results of the year long Massachusetts pilot study, and the reasons for the plug-in RFi, we realized that our real challenge was first cracking into the bound business processes, and second, providing an alternative solution at the business process level.

In this context, the da Vinci plug-in only worked as a holding action. We believed we could neutralize MSOffice, and put the business processes on an ODF iX footing. But that's as far as a plug-in could go.

Enter the grand convergence requirements. These came about as an answer to what to do with those MSOffice business processes once we got into a position where it was possible to re purpose MSOffice.

As clone makers, the da Vinci group knew the purpose of MS-OOXML went far beyond that of replacing the existing binary formats. MS-OOXML is designed as an efficient transport of MS Stack business process information reaching across the MS cloud specific grand convergence of MS desktop, servers, devices and web systems.

In this context, MS-OOXML is also the migration path for moving MSOffice bound business processes to the Exchange/SharePoint Developers Hub. And they are moving. While the world is obsessed with the file format war, Microsoft is quietly migrating all those business processes to the E/S Hub. From there, these newly re written collaborative processes are being connected to the rest of the MS Stack of MS Live, MS Dynamics, MS SQL Server, MS Office Communications Server, etc.

There is no doubt that the E/S Hub is the core against which the new business processes will be written. And sure, MSOffice gets relegated to the role of a rich end user interface into the Hub, albeit an essential interface. But look what happens as the MS Stack emerges. The desktop monopoly rolls out and extends across servers, devices, and the web.

We felt that if we could neutralize and re purpose MSOffice with a plug-in, same as Microsoft does with the MS-OOXML Compatibility Pack plug-in, we could open up a level playing field of competition against the Exchange/SharePoint juggernaut. The hope being that open source and proprietary but W3C compliant systems would move in at that level to compete against the E/S juggernaut. If only we could hold the door open for them, and provision their connection into the MSOffice installed base with a non Microsoft owned file format.

All we are doing is watching the Microsoft game plan very carefully, from our rather unique cloning perspective. From that perspective, the file format debate is in many ways a camouflage covering the very real movement of these bound business processes into the MS Stack cloud, where Exchange/SharePoint Hubs anchor extraordinary and productive collaborative engaging re writes. This is a very different problem set than that of desktop office suite to desktop office suite document exchange.

It's a small role to play in the larger scheme of things. For sure it's late in the day. The MS-OOXML migration of business processes to the Exchange/SharePoint hub is upwards of 50% complete. Some industries like Real Estate have already fallen, with Insurance and financial services not far behind. The day where we could have neutralized and re purposed the entire 550 million MSOffice desktops has come and gone. Today we're looking at a much smaller opportunity, but nevertheless worthwhile. Especially if you're a few guys without a garage.

The da Vinci group continues to believe that CDF WICD Full 1.0 work can anchor the emergence of an open, W3C based WICD Stack as an effective alternative to the MS Stack. This despite the loud insistence by IBM, the W3C, and the OASIS lawyer that CDF is not up to this challenge. Time will prove this out. But here is a very important distinction that must be made; This is all about competing against the MS Stack in the cloud.

Let's change the angle of the argument just a bit to shed some light on the technical challenge. MS-OOXML was designed to work in this cloud, and Microsoft has provided an easy to implement conversion process positioning the installed base of MSOffice desktops as rich end user interface into the MS Stack cloud. The challenge for the da Vinci group is to perfect a similar conversion of MSOffice bound documents, applications, and processes into the cloud of CDF WICD Stack alternatives.

Although IBM has come down hard on CDF, i find it hard to believe that they aren't facing a similar conversion challenge with Lotus Symphony. They too need to get information (and information processes) off the desktop and into the Lotus Notes centric cloud. Given their participation with CDF WICD, it's hard to believe they would enter their cloud, or any other cloud, through a non W3C route.

Time will also reveal the truth about Microsoft's strategy of masking the migration of bound business processes to the Exchange/SharePoint Hub and into the MS cloud. So let's agree to revisit this discussion when it is clear as to how Microsoft succeeded in getting the world to look the other way, while behind the scenes they somehow managed to pull this off. Bring a box of kleenex, just in case.

~ge~

alphadog

First, let me say that I am a CIO in a small (20 employees but growing fast) financial services company.

I am well aware of how locked-in I am getting with our MS-only shop. I am trying to see my way out of it, but this "ODF vs ODFF" is leaving me very confused and no one is working to clear the fog.

I beg for all parties to really work towards some sort of defined understanding. I don't need cooperation. But, what I don't have is well-defined positions from all parties.

As it is, I feel safer staying the course with MS right now, honestly. It's what I know vs the mystery of this "open cloud" and all the bellicose infighting.

How's that for "in the trenches" data?

I posted a comment on Andy's blog, and I will post the same comment here for your group (minor edits):

I will admit to being very, very confused by all of this ODF vs ODFF posturing.

I will try to put my current thoughts in short form, but it will be a muddled mess. I warned you!

From what I gather, the OpenDocument Foundation (ODFF) is attempting to create more of an interop format for working against a background MS server stack (Exchange/Sharepoint). You worry that MS is further cementing their business lock-in by moving more and more companies into dependency on not only the client-side software but also the MS business stack that has finally evolved into a serious competitive set. At that level, and in your view, the "atomic unit" is the whole document. The encoded content is not of immediate concern.

ODF is concerned with the actual document content, which ODFF is prepared to ignore. The "atomic unit" is the bits and parts in the document. They want to break the proprietary encodings that MS has that lock people into MSOffice. The stack is not of any immediate concern.

So, unless I misunderstand either camp, ODF is first attacking the client end of the stack, and ODFF is attacking the backbone server end of the stack. The former wants to break the MSOffice monopoly by allowing people to escape those proprietary encodings, and the latter wants to prevent the dependency on server software like Exchange and Sharepoint by allowing MS documents to travel to other destinations than MS "server" products.

Is this correct? I have yet to see anyone summarize the differences in any non-partisan way, so I am at a loss and not enough information is forthcoming for me to see what's what. The usual diatribe by people closer to the action is to go into the history of ODF or ODFF, talk about old slights and lost fights, and somehow try to pull at emotional heartstrings so as to gain mindshare. Gary's set of comments on this blog have that flavor. This is childish on both sides.

Furthermore, the word "orthogonal" comes to mind. I often see people too busy arguing their POV, and not listening to others, when there is no real argument to keep making. It's apple-and-oranges. ODF vs ODFF seems like they are caught in this trap. Everyone wants to win an argument that has no possible win because the participants are not arguing about the same thing.

Tell me: Why can't the two parties get along? I can see a "cooperative" that attacks the entire stack. Am I the only one seeing this? Am I wrong? If yes, what's the fundamental difference that prevents cooperation?

Sam Hiser

alphadog -

You are understandably confused about the Foundation's role, which is: closed for business, no longer involved in ODF development.

As for your questions about what to do, these are important. We can speak to you and even make sure you come away with a clear understanding of the shifting landscape.

For the time-being, stay clear of Office 2007 and its OOXML formats and especially stay clear of Sharepoint if you can. Use nothing later than Office 2000 or 2003 and remain standardized on the .doc and .pdf formats.

Gary Edwards

AlphaDog

When asked about the source of his incredible success, the hockey great Wayne Gretzky replied, “I skate to where the puck is going to be, not where it has been.”

You and i need to do the same. Let me state our position as this: The desktop office suite is where the puck has been. The Exchange/SharePoint Hub is where it's going to be.

The E/S Hub is the core of an emerging Microsoft specific web platform which we've also called, the MS Stack. In this stack, MSOffice is relegated to the task of a rich client end user interface into the E/S Hub of business processes and collaborative computing connections. The rest of the MS Stack swirls like a galaxy of services around the E/S Hub.

Key to Microsoft's web platform is the gradual movement of MSOffice bound business processes to the E/S Hub where they connect to the rest of the MS Stack.

So what now you might ask? Some things to consider before we get down to brass tacks:

... There is a way to break the monopolists MSOffice desktop grip, but it's not a rip out and replace the desktop model. It's a beat them at the E/S Hub model that then opens up the desktop space. And opens it up totally. (this is a 3-5 year challenge though since it's a movement of currently bound business processes).

... It's all about the business processes. Focusing entirely on the file formats is to miss the big picture.

... The da Vinci group's position is this; we believe we can neutralize and re purpose MSOffice by converting in process existing documents, applications and processes to the web platform ready CDF WICD Full format.

... This in process conversion is only half the problem. We still need CDF WICD Full ready applications that can compete against the Exchange/SharePoint Hub.

... It is far easier to convert OpenOffice ODF to CDF WICD Full than it is to convert MSOffice binary - xml to CDF WICD Full. We fully expect IBM, as a W3C CDF leader, to perfect an ODF to CDF WICD Full conversion. The da Vinci groups challenge is pull off this same conversion targeting some segment of the 550 million MSOffice bound desktops that have not yet been migrated to the E/S Hub.

... Once in CDF WICD Full, the documents are web platform ready, highly interoperable, and available to E/S Hub alternatives. The MSOffice monopoly advantage is arguably neutralized at it's head point, the MSOffice desktop.

... The battle against the MSOffice <> E/S Hub juggernaut will be won or lost based on volumes of business processes being re written to Open Hub alternatives. It will not be won (or lost) at ISO or other standards groups. Ultimately the marketplace will decide.

... The day after IBM informed Sam and i of their grand strategy involving W3C centric CDF technologies, based on the fluid web platform conversion of Lotus Symphony ODF to CDF *, we shut down the Foundation. The point of our agreement being that we meet in the cloud with CDF * conversions. IBM will bring OpenOffice ODF into the cloud. The da Vinci group will bring MSOffice binaries and xml documents.

Here are some viewpoints that might help you make the conceptual shift we've made.

Since i've been writing about the Open Stack vs. MS Stack challenge since long before i joined the OASIS ODF TC at it's founding in November of 2002, it was natural that i brought to ODF a universal file format vision that extended far beyond the desktop. In many ways, my relationship with OASIS ODF was doomed from the start since my grand convergence ideals were at fundamental odds with Sun's.

This five year clash of ideals and purpose is responsible for your confusion, and perhaps that of many others. In fact, Sam and i are personally responsible for writing much of the ODF kool-aid, setting public expectations and beliefs to our universal file format objectives; which admittedly went way beyond the desktop centric chartered purposes Sun had set and followed.

Let's try a few statements that will hopefully frame the context within which CIO's can determine for themselves what is the best way forward. Note that through conversions to CDF WICD Full, all of our previous differences can be resolved at the Open Hub, in the cloud.

If you think the purpose of MS-OOXML and the MS-OOXML Compatibility Pack plug-in as simply an XML replacement for Microsoft Office binary file formats, you miss the true purpose of MS-OOXML.

If you think that MS-OOXML is simply a proprietary response to OASIS ODF, you really misunderstand what Microsoft's end game strategy is.

MS-OOXML was designed to work at both ends of the MS Stack core pipeline, connecting MSOffice with the Exchange\SharePoint Hub, which is the core of the Microsoft Web Platform.

ODF on the other hand was designed exactly for the purposes it's name implies, "OASIS Open Document Format for Office Applications (OpenDocument) TC. It's a desktop office suite specific XML file format. ODF was not designed for the same purposes as MS-OOXML. It was however designed for a very fluid conversion of desktop to W3C web platform technologies.

Think of MS-OOXML as a transitional bridge for moving legacy MSOffice bound business processes to be re written at the Exchange/SharePoint Hub by vertical line of business developers. These replacement business processes are Microsoft web ready, and fully capable of leveraging the advantages of web collaboration, intelligent workflows, and stack wide data streaming, data binding/extraction, and web service integration.

In many ways the file format wars are a front masking the quiet but massive movement of MSOffice bound business processes to the Exchange/SharePoint Hub.

This is what you and i must focus on. We have a rare opportunity to compete against this quiet but massive movement of business processes, but only if we can empower open source and proprietary competitors to be fully competitive with Exchange/SharePoint. For the most part this means taking away the E/S Hub advantage of superior integration with MSOffice.

The da Vinci group is uniquely qualified to take on this challenge. Our conversion process is based on the same internal conversion process MSOffice applications use to generate MS-OOXML. We believe that CDF WICD Full can perform at the Open Hub layer similarly to the advantages MS-OOXML provides the Exchange/SharePoint Hub.

Don't confuse the Hub with the desktop. They are different. Hub documents must be fully web ready and desktop - device ready.

The challenge for the da Vinci group is that of piping in process MSOffice documents into CDF WICD Full without loss, and without disrupting existing bound business processes. There is also the issue of maintaining this bridge between legacy desktop business processes and new Open Hub business processes written to emerging Hub powerhouses like Zimbra and Alfresco.

Please note that while IBM Lotus Notes-Symphony work is proprietary, and that the da Vinci group itself is a private operation, the CDF - WICD galaxy of W3C ecosystems is enormous. Mozilla, Apache and the Eclipse Community are areas of intense development and innovative implementations.

What to Do

Do not buy Exchange/SharePoint servers. Do not buy MS Office Communications servers. In fact, stop buying into anything Microsoft offers. The MSOffice desktop lock-in can be broken by re writing your business processes to Open Hub alternatives like Zimbra and Alfresco. Once you get the business processes to an Open Hub, you can start replacing the MSOffice desktops with open alternatives.

Focus on W3C technologies as the driving components behind everything you do with the web platform.

Go to the CDF - WICD developer communities such as Mozilla, Apache and Eclipse, and let them know what you've determined are your primary friction points.

And finally, understand that the web platform is where the puck will be. For everything.

Hope this helps, and thanks for the pointed questions,
~ge~

The comments to this entry are closed.


Sam Hiser

Categories

OFF-WHITEPAPERS

ARTICLES


www.flickr.com
This is a Flickr badge showing public photos from swhiser. Make your own badge here.


Locations of visitors to this page


Google
Search PlexNex

  

View Sam Hiser's profile on LinkedIn

Powered by TypePad