Terms of Enduring Interoperability

Once again, great coverage and discussion at Groklaw: GROKLAW So, what does an AMD anti trust - illegal collusion and racketeering lawsuit against the WinTel monopoly have in common with the rise of Open Source Communities and the increasing imporatance of Open Stnadards work? Both are based on WinTel breakign with the cornerstone of the empire, the X86 - Win32 API franchise. Perhaps the greatest monopolistic franchise ever conceived and executed. An interoperability cartel now crashing. An essential carrier set ablaze. Here's my take on a story just beginning to unfold, "The AMD Subpoena to Microsoft": Two steps forward, one step back. Time to clean up the mess that was WinTel, once and for all. The AMD story is one for the ages. They took a wild, beyond risky shot at taking on the Tel part of the WinTel empire. And somehow they won. The risk they took was based on a government mandate that Intel license the X86 architecture to would be competitors. This mandate reminds me of the DOJ settlement with Microsoft mandating that Microsoft license the middleware API's to would be server, device and desktop competitors. Intel however agreed to offer comparatively reasonable licensing terms that, although reasonable, would no doubt preserve the serious advantage they had. While Microsoft was allowed to charge whatever they wanted – as in whatever was reasonable in light of their efforts to extend their monopolist domain. The only requirement being that some MS cartel members would actually pay the price asked for access to the monopolist jewels. Intel had to provide equal access. Microsoft continues to operate as if this inside information was a special permission that comes with strings and obligations. Against all odds, AMD took a long shot and prevailed, catching and tripping Intel exactly where Intel tried to replace the 32 bit X86 architecture with a newly proprietary IA-64 instruction set. From Wikipedia, “the IA-64 (Intel Architecture-64) is a 64-bit processor architecture developed in cooperation by Intel and Hewlett-Packard, implemented by processors such as Itanium and Itanium 2. The goal of Itanium was to produce a "post-RISC era" architecture using EPIC.” Translated, the new IA-64 instruction set was not compatible with the old X86 set. AMD developed an AMD64 bit extension to the X86 set, and achieved far better performance, able to run with the vast investment in X86 legacy applications written to the Win32 API. The IA-X86 escape instructions Intel came up with to run the wealth of legacy Win32 API applications totally bombed. Intel eventually choose licensing the AMD64 set over being driven out of business. Talk about turning the tables! And now AMD has enough power and influence to exact revenge and demand enforcement of the Rule of Law. Finally. I don't doubt for a second that Microsoft isn't in a similar position today. The critical point is again the legacy of Win32 bound applications, services and business processes. Almost the entire monopoly base of 450 million desktops is bound to the Win32 API. Yet, here's Microsoft pushing forward with a .NET – WinFX – XAML – C# - MSECMAXML bound XP-Vista stack. The Win32 API and all those legacy Windows desktops are being EOL'd, support, maintenance and security fixes having long ago ceased. Even on XP Professional there are serious problems for legacy Win32 applications and drivers, rendering whole application libraries and business processes next to useless. It will be far worse when Vista is released. Here's the thing; there is no AMD type corporate competitor in place to step into the Win32 API breach, and carry those 450 million desktops into the age collaborative computing. And do so with consumer legacy code investments intact and performing as expected. What we have instead is a gaggle of cross platform open source efforts able to deliver collaborative computing within the Win32 API boundaries. Lead by core productivity components, OpenOffice.org and Mozilla.org, a cross platform open stack of applications able to provision an XML ready desktop productivity environment is just a download away. If KOffice ever makes it to the Win32 API, all hell is going to break loose, and Microsoft will have to fight like crazy to hang on to their monopoly. The empiric half of the WinTel empire will be facing the ultimate challenge; being undercut by outsiders who are seizing a rare moment in time. The moment when Microsoft abandons the Win32 API, and tries to force march at great cost and disruption, an angry user base. Marching them into a collaborative computing future. Ever under the iron fisted control of Redmond, this time across the entire integrated stack of XP-Vista OS, desktop applications, middleware, API's, devices and server suites. AMD got into position via their own tenacity and a long overdue government mandate. Microsoft is exposed because of a hubris so elevated, so nauseating, that they have lost all respect for developer network, their vast cartel of trading partners, and the legendary user base long the envy of furtive monopolist and empiric dreamers the world over. They were found guilty of some of the most illegal and reprehensible business practices ever brought before a court of law. Activities so lacking in any ethical or moral grounding as to make Enron execs look like a bunch of boyscout's gone bad with some wayward copies of National Geographic. And they got away with it. Hence a hubris and disdainful disrespect unlike anything we've ever seen. Thinking about it, i now wonder if the current DOJ Settlement was crafted in a fashion similar to the Intel mandate that gave AMD a second life. Obviously the European Union disagrees. They want those XP-Vista middleware API's released without encumbrances or access barriers. IMHO, the heart of the deliciously named Microsoft Anti Trust trial was the issue of an essential carrier. In the case of the X86 instruction set, Intel was alleged to be an essential carrier of computation. In the case of Microsoft, Windows was found to be an essential carrier of computational applications and services. There is something about connectivity, transport and messaging“carriers” that the laws of efficient use of shared resources and public access are warped into non competitive arrangements. Things like bridges, railroads, turnpikes, cable, copper wires, electrical transmission, radio frequencies, and computational platforms have led to either public ownership or public regulation. The one thing we don't find is competition. Building a second Golden Gate Bridge to compete right along side the original just doesn't make any sense. With Open Standards and open architectures, it's entirely possible to build computational systems out of highly competitive components. Possible as long as everyone agrees to the open standards for interfaces, protocols and methods that make such interoperability between competing components possible. But who has the foresight to predict which technologies will become essential carriers? Is it possible that we are now entering an age when the challenge of winning critical mindshare and marketshare is terminally clouded by concerns over open standards, open Architectures, and open licensing models? I think so. I think the days of the X86, Windows OS, and the controlling dominance of the Win32 API are gone forever. Lesson learned. Now the challenge is to break loose from our sordid past, and never make the same mistake again. The answer to the essential computational carrier question is now bound up with concerns for open standards and the methodologies of open interoperability. The balance now sways with open source communities who excel in both these areas. Things are changing. Perhaps much faster than vendors suspect. The old game had these rules; if a vendor, or royalty sharing consortia of vendors can set the “standards” for how things connect, interface, interact and exchange, they can control markets. Control the terms of interoperability, and you get to drive price and eliminate competition for years to come. Through control of standards and the standards process, ruthless supply side opportunist could dictate the terms of demand. Brian Behlendorf comments that there are only two industries that refer to their customers as “users”. Both industries share the characteristics of extremely high profits for those who are in control; and, collusion between would be competitors to carve up markets, eliminate competition, control of supply, distribution, and the terms of demand so that high profits are perpetually maintained. In one industry these activities are illegal, even declared to be a threat to national security and the well being of civilization. In the other, these same activities are for the most part legal unless and until a monopoly has been officially declared. Governments declaring at that point that such collusion has gone to far, open and competitive markets need be restored, and the Rule of Law (especially contract law) enforced. Information technology consumers who get hooked on a suppliers proprietary standards are continually pushed to purchase more from that providers cartel in a never ending cycle of higher prices for less functionality. There are two ways for consumers and outside the cartel technology providers to get back in the game; Open Standards and Open Source implementations of those standards. Personally i don't believe one is possible without the other. Least ways not in a meaningful, lasting manner that truly guarantees that markets will remain open and competitive, and, that consumers will finally be able to take ownership of both their information and their information processes. The emerging relationship between the open standards process, FLOSS influence, and participation in that process is exactly how the rules of the game are changing. It's still early in the day though. That FLOSS was central to the build out of the Internet is beyond doubt. A few open protocols, methods, and interfaces quietly brought the Internet to the point of notice as an alternative platform of communications and collaborative computing. The Netscape IPO brought the Internet into full public awareness, and the race to commercialize what had been a public commons took off. And with that blast off came the effort to assert control through the proprietary twisting of what were soon dubbed “open standards”. Corporate consortia proposals for vendor controlled standards followed the incessant twisting of open standards. Both efforts designed to wrest control of the Internet away from FLOSS and common public use. These efforts were followed by much consortia posturing aimed at fooling the public into thinking that patent encumbered and license restricted standards proposals were actually big letter Open Standards. The days of the Open Internet looked to be numbered. Put me in the camp of those who would argue that Microsoft's war against Netscape and Java were part of a larger effort to seize control of the Internet. Or at least to take command of Internet based opportunities. This first war was followed by an assault against the GPL and Linux, the powerful one two punch at the heart of the exponentially exploding FLOSS community development riding the wave of a global and open Internet. The assault on the GPL and Linux has masked another, perhaps far more serious assault launched on the next generation Internet API, “Open XML”. This shouldn't come as a surprise in that XML is the future of the Open Internet. If you seek to control the Internet, you have to somehow seize control and assert ownership of XML. Since XML is owned, developed and openly licensed by the W3C, it's very difficult to assert patent claims or ownership rights over the basic XML methods and technologies. But given what is at stake, control of the Internet, hungry vendors quickly go to the next best thing: seeking patents over XML methods and implementations – over “how” XML is used - and, asserting consortia control over the standards processes governing these implementations. FLOSS communities have such power of participation and marketshare, that i think they can bring daylight to the corrupt patent assertions , and, balance to the open standards process. FLOSS alternatives to proprietary software and services are proliferating, and with that proliferation comes a greater awareness of the factors of great interoperability: open interfaces, open messaging and communications protocols, open run time engines and libraries, and Open XML technologies – including file formats. What the Open Internet and FLOSS share is that they are each a living, thriving embodiment of how things can connect and work together. They also scream loudly to the world what it is that is lacking in proprietary integrated technologies and consortia controlled standards processes. Their very existence shouts out that indeed, the emperor has no clothes. As the Internet and XML increase in importance, invading every systems stack of software and services known, there is a parallel rise in public awareness of how important Open Standards and Open XML technologies are. Governments are now routinely writing into their requirements binding definitions and demands for Open Standards and Open XML technologies - leaving vendors increasingly less room to wriggle, wrangle and obfuscate. A box that seems to get tighter with each new requirements release. One of the most important movements to watch is that, as the demand side of the information technology marketplace becomes more involved in the open standards process, so too must FLOSS communities. This is happening, but slowly. On the OASIS OpenDocument XML TC, the process was very much multi vendor – multi market driven except for one important factor. The two reference implementations that everyone worked from, and every aspect of the OD XML spec was routinely tested against, were the FLOSS implementations; OpenOffice.org and KOffice. The influence of ever present FLOSS communities worked to insure that there is nothing theoretical about OD XML. Proposals to enhance or change the specification were scrubbed by community developers and project managers before making it into the formal specification. The proposals were public, and so was the participation in how implementation issues were resolved. This benefited the vendors involved in that they didn't have to disclose trade secrets or compromise their corporate works by participating in the collaborative process demanded to prove out a particular proposal. The OD XML spec benefited in that it was road tested at the proposal level by a widely divergent but highly collaborative group of developers. The participants were familiar with an impossibly wide range of issues, spanning from possible interfaces, across platforms and systems infrastructures, and into the many layers of interoperability demanded by legacy connectivity and compatibility with emerging collaborative computing needs. No matter what the problem, someone somewhere on the Open Internet had been working on that same problem, and were more than willing to contribute their expertise. The OASIS ODF TC work now extends through four primary information domains: the desktop productivity environment; publication, content and archive management systems; SOA efforts; and the Open Internet. With Plone CMS ODF round trip capability becoming the most recent announcement. I would argue that the ODF implementations are far more important at this point than the continuing open standards work at OASIS. The ODF 2.0 work will contain some extraordinary advances concerning Accessibility, Open Formula, and a Semantic Web Metadata model. But those enhancements would not make sense, nor would they be proceeding so fast, if not for the expanding ecosystem of often hybrid vendor and FLOSS efforts pushing ODF into parts unknown and uses never dreamed of. In many ways the involvement of FLOSS in the ODF standards process has set the high bar for open standards in general. It may even be a peep into the future, where FLOSS communities work everywhere with vendors and technology consumers to craft open standards certain to accelerate the advance of this digital civilization. If anything, i believe the increasing involvement of FLOSS in Open Standards will help insure that the Open Internet remains owned by none, open and useful to all. The terms of an enduring interoperability are baked into the FLOSS DNA. And that's a good thing. ~ge~

Open or closed? The ODF debate spills into LinuxWorld

Open or closed? The ODF debate spills into LinuxWorld

Well, at least author Jack Loftus got the title right. This discussion is all about an Open XML file format wrapper for Open XML technologies. MSECMAXML is an open XML wrapper of closed proprietary technologies. Calling MSECMAXML "Open XML" or Office Open XML" is dishonest and intentionally misleading. Here's why. First of all the W3C is the inventor and owner of Open XML technologies. They developed those technologies so that XML and RDF would succeed HTML and greatly extend the value and effectiveness of the Open Internet.

Second, the official name of the original 2002 Open Standards effort was "OASIS Open Office XML", not OASIS OpenOffice XML (which is the original name of the XML file format specification when it was submitted to OASIS in 2002). The OASIS Open Office TC (Technical Committee) changed the name from "Open Office XML" to "OpenDocument" at the request of the EU. Yes, that's right. The EU requested the name change in response to continual complaints from Microsoft. The EU had determined that their long term SOA future depended on Open Standards and Open XML technologies. They also recognized the incredible value of having one XML file format that could cover most if not all of their information needs, directly or through extremes of interoperability and clean transformation capabilities. Microsoft refused to support and implement a file format named after the only possible threat to their MS Office cash cow, the cross platform and open source OpenOffice.org productivity environment.

So far this makes sense. No one would blame Microsoft for that complaint. If only that were the end of the story. Hardly. We know now that Microsoft was beyond disingenuous in their demands for a name change. Within four days of the EU request, the OASIS Open Office TC changed the name to "OpenDocument XML", which was unceremoniously hyphenated to "ODF" by über analyst Stephen O'Grady of Redmonk. The name "OpenDocument" comes out of the Valoris Report. This was the fictional XML file format they used in their projections and use case discussions to demonstrate how critically important an Open XML file format would be. It's also important to note that the Valoris Study identified complete separation of the file format from application and systems specific software dependencies as a most important characteristic. They provided the EU with a definition of Open Standard and Open XML that includes this "separation". And so it is that the first universal file format was described: one able to address the needs of desktop productivity, publishing, content management, archiving, SOA interoperability, and Open Internet use. One that would be good for the next 200 years. So what does Microsoft do? They change their XML referencing from WordML to MSXML. Which changed again to "Office Open XML" when they submitted the specification to their hand picked ECMA workgroup.

Hummm. Let me see. It looks to me like they wanted the name "Open Office XML" to disappear so they could glom onto "Office Open XML". I refuse to bite. For me the only accurate description of this application bound and platform dependent XML wrapper is "MSECMAXML". One company in control. One iron fisted standards process posturing as "open" with a charter specifically stating the intent is to make “MS Office Open XML” a standard. One implementation, and that isn't available yet.

But hey, it is XML. Mr. Loftus does have a great line when he asks, "Do users know the difference between the open standards-based OpenDocument format (ODF) and proprietary ones like Microsoft Office Open XML?" I wonder if he was laughing when he wrote that? Some other points in the article ruffled me a bit. Here's one by John Walker of Versora, "Office Open XML was designed to be sensible, Walker said, while ODF was designed to be open. Microsoft's offering is also a more robust platform compared to ODF's less complex model. "Microsoft has thought a lot about document recovery [with Office Open XML]," he said. Wait a second, MSECMAXML was designed to meet Microsoft's needs. Yes, if you're Microsoft it is very sensible. I f however you are a Microsoft consumer quite happy with your current MS Office investment, this becomes a sales pitch to upgrade your existing productivity environment to WinXP-Vista and MS Office 12. The bonus is that you get to take all your MS Office bound information with you.

I think that is what Mr. Walker means when he says, "Microsoft has thought a lot about document recovery". In an interesting article titled, "Corporate Alzheimer's: Coping With Forgotten File Formats", John Walters quotes from Microsoft's Brian Jones, lead program manager for the Office suite. "It's true that the feature set Open XML enables is a reflection of the Office feature set," he says. "We had to go with a format that was, from the ground up, designed to support all of our legacy systems." Yes, MSECMAXML was designed specifically for MS Office 12, and designed so that the legacy of MS Office file formats can be transitioned forward. Don't think for a moment that your trusty MS Office 98 or MS Office 2000 application suites will be able to read/write MSECMAXML. You can bet your bottom dollar that a massive hardware-software upgrade to XP-Vista is in your future if you decide on MSECMAXML. Oh, did i mention that you can have all the collaborative computing features of an OpenDocument ready environment today - without upgrading anything? Just download the cost free no procurement hassle here OpenOffice.org - Mozilla.org combo, and make that leap into the future. The vendor support discussion in this article was very misleading. Yes, ODF does have a broad range of support with over 30 vendors now in the market with ODF ready products and services. There is explosive activity in the emerging Web 2.0 sphere, with AJAX, XUL, DocVert, and XForms ODF type services and solutions proliferating. But this part is misleading, "Walker also pointed to differences in vendor support. With Microsoft, the support is deeper, as studies show Office still in control of 95% of the office applications market." Why? The 95% of the applications market cited could be running ODF today with a simple, cost free download. But they certainly are not running MSECMAXML! It's not even available for the most advanced XP MS Office systems out there, (of which there are comparatively few installs), let alone the massive installed base of Win98, Win2K, and WinXP 2003. The monopoly base is simply not an advantage to Microsoft here. It's an advantage to ODF and the easy to download and install today OpenOffice.org - Mozilla.org productivity environment. It's an advantage to gWritely, ajaxWriter, DOJO, Apache, and MediaWiki.

For Microsoft this is one of the most serious problems they have ever faced; how to compel and force march over 450 million Windows users to XP-Vista MS Office 12 and the promise of MSECMAXML. The good new is that you get to take all your MS Legacy Office bound information with you. Happy marching! The future is one of ever more capable, interactive, and effective Open Internet based collaborative computing. In this future XML::RDF is everything. As a means of entering into this future, one can choose either an ODF ready environment and get there today with your existing computational investments, or, wait for XP-Vista MSECMAXML, throw away your existing systems, and replace everything to become once again part of another Microsoft controlled profit stream. Is there a decision here? Let's move on to the complaints about ODF. Okay, so there isn't an ODF ready application suite as complex and bloated as MS Office 12 promises to be. But then, even though the feature set of OpenOffice.org is more focused on critically important productivity tasks and services, the re training and learning curve for the pricey MS Office 12 ought to give every upgrade pilgrim pause. One thing i would point out is that MS Office has nothing like IBM's ODF ready WorkPlace. Nada, zip, squat, buttkiss, dusted. They've got nothing that can compare to the workflow and business process - information management that the highly collaborative WorkPlace offers. And then there is gWritely, the highly collaborative WikiWare and on line document management system. Writely is able to handle .doc and ODF documents. No mention of MSECMAXML.

Given the platform specific dependencies that riddle the MSECMAXML specification, the conversion process (if it's legal) is going to be a nightmare for AJAX, XUL, and XForms collaboration services. There is the complaint in the article that ODF ready applications do not adequately address the "accessibility" needs of physically handicapped or impaired people. Following the Armonk ODF Summit, the OASIS ODF TC immediately chartered an "Accessibility" subcommittee to address this. This work is proceeding at an accelerated pace, and hopes are high to produce results by this summer - well in advance of the MASS ITD 2007 deadline.

It's interesting that the accessibility extensions being proposed for the desktop productivity environment will also work across the Open Internet as highly accessible "interactive" Web documents. These extensions are going to benefit everyone. For the accessibility challenged, the mesh of audio, visual, and peripheral sensitive extensions are going to open up a galaxy of information and collaborative participation processes they have long been denied access to. For those not directly "challenged", the benefits will be that of a massive leap in multi tasking capabilities. Those who are used to doing ten things at once are going to have the chance to up their game to twenty or thirty. The final statement in this article also caught me short, "Also on the critique docket is the fact that ODF designers limited extensions on purpose to discourage companies from making proprietary ones -- much in the same way Microsoft did with ActiveX and Java." First, I don't get the ActiveX - Java statement. With Java, Microsoft tried to secretly introduce proprietary extensions that would only work on a MS Windows JVM. The extensions were designed to break the standard JVM - all of which was a clear violation of the license agreement with Sun. Microsoft was found to have done this with the express intent of destroying Java for anyone not working off the Windows monopoly platform. I don't get how this kind of deceitfully reprehensible and contractually illegal conversion of opportunity relates to anything done by the OASIS ODF TC? I'm lost on this one. The issue of a base line implementation with proprietary extensions above the base line has long been a concern of the ODF TC. What we tried to do is embrace and implement Open XML technologies and methods within the base line so that proprietary extensions could be pushed up above the base, addressing those needs where there was no other alternative but to fork. The quality and depth of the base line defines the fidelity of interoperability and transformation. The minute you fork from the base line, the measure of interoperability and transformative quality declines. So the ODF designers try to provide markets with a volume base line that meets all of their common and expected interoperability use cases.

It's not all that hard building a volume base line. Just stick to Open Standards; open interfaces and methods, open messaging and communications protocols, and most importantly, Open XML technologies coming out of the W3C. There is no question that market categories and vertical industry implementations will need to introduce "extensions". These extensions can be proprietary or open. We hope they are open, but there are many legitimate situations where a closed or boxed set of extensions to ODF make sense - proprietary or not. Since ODF is an "Open Standard" in every sense of the term, there is no way "the designers" can "limit extensions on purpose to discourage companies from making proprietary ones..." Corel or Microsoft, or the National Association of Realtors, or anyone else can take the ODF specification and implement their own extensions and dependencies. Microsoft could go through the spec and replace HTML with MSHTML, or SVG with Sparkle. Or, they could leave the ODF dependencies in place and introduce the proprietary extensions above the baseline.

They could have done this and provided developers and information systems architects with a road map of dependency substitutions. That would have greatly eased the problems of interoperability and clean clear transformations. But they didn't. Guess what Microsoft did choose to do? Right, they chose to fork from Open XML as soon as you crack open the wrapper. What's inside a MSECMAXML file is a cascading entanglement of MS proprietary platform dependencies. It's often been said that the goal from MS has always seemed to be to replace the Open Internet with MSN. The XAML/Avalon Vista design has no support for CSS, XHTML, XForms, SMiL, DOM or SVG. This observation is further born out by the 1900 pages of the MSECMAXML specification and restrictive reference license. One way of looking at the proprietary extensions claim is to view the ODF objections of someone like OASIS LegalXML. They disagreed with the way ODF handles "styles", and instead of introducing their own proprietary extensions to get the features they wanted, they set out to invent a completely new LegalXML language. That's okay, except they now have to go out and spin up a new application sector too. XML languages are difficult to invent, monstrous to maintain, a bear to build community around, and then, when you're finally ready to introduce your efforts to the marketplace, a nightmare of arguing against the high risk investment shroud that hangs like an albatross around any new language - business process revolution. The good news is that the OASIS ODF Metadata Sub Committee will solve all the LegalXML problems in spades. The ODF LegalXML::RDF solution will make it into the next release of the ODF spec, and with it will come volumes of application and service providers ready to take on the Legal industry challenges. Will there be Legal extension's to ODF? Of course. But there will also be a volume base line and universal metadata model that will enable legal librarians and practitioners to define conceptual relationships and manage volumes of documents in ways they never dreamed possible. Let me close with this. The submission declaration and charter for MSECMAXML were extensively covered by standards expert Andy Updegrove who summarized his findings with this chilling indictment: "In summary, what I read here is the following: the working group would be told to take the offered schema and convert them, without change (or charge), into a standard, apply the EDMA imprimatur, and then submit them to ISO, so that users of Microsoft Office may seamlessly use their documents in conjunction with other conforming software, and so that Microsoft may obtain a unique market benefit. The working group would also be told not in any way diverge from this goal in order to improve the standard, or to address the needs of the users of any other products in existence, or to accommodate the functionality of any other product, or to serve the interests of any other vendor, or of any customer that has needs that cannot be served by Microsoft Office.

I would submit that such a request is not consistent with the role of a standards body, but rather the diversion of an organization created to serve the needs of an industry to the unique demands of a single vendor. Were ECMA to be based in the United States, I would not be surprised if accepting such a charter would result (if discovered by the IRS) to the loss of the standards developer's tax-exempt status. . . .

A final note: as expected, there is no mention in the charter of any special IPR requirements that would be imposed on any member of ECMA. This would indicate that while Microsoft may renew it's royalty-free commitment, any other member(s) of ECMA with a relevant patent would have the right to charge a royalty to implement the resulting standard, or to require terms that would be inconsistent with open source licensing."

Thanks Andy. Your comments should be must reading for everyone.

~ge~