Matusow's Blog

Hello World…Again

jasonmatusow — Wed, 08 Jul 2009 23:52:35 GMT

It is time to start blogging again. I have received many emails asking where I went. The simple answer is…I’ve been working. I know that sounds lame, but the truth is that I have been heavily engaged in some internal projects at Microsoft and it was enough to keep me from staying with my blog.

I just went and checked and my first “Hello World” was on March 9, 2005. So, 4 years later it is time to start all over again. Back then I was writing about Open Source Software. Somewhere along the way I shifted over to working on industry standards, and there I have remained.

When I last posted in 2008, my blog had completely given over to document format discussions. While interesting in and of themselves, it is important to keep our eyes on the broader context.

Over the past year, the continued growth in interest around eGovernment, the increased attention being paid to Health Care IT, e-Learning, and a continuation of global interest in interoperability as a concept have made standards all the more important.

Looks like there is tons to talk about, so hello world…again.

A Macro Question About Microsoft And Standards - Oh Yeah - And Is Microsoft Really Committed to Open XML?

jasonmatusow — Wed, 25 Jun 2008 01:35:29 GMT

A colleague of mine, Stuart McKee, sat on a panel recently during a Red Hat event. His comments have drawn some attention, and now some FUD that I really feel needs to be addressed.

First of all, you can see the coverage here, here, here, and here. But the one I most want to comment is this one from ZDNet in the UK.

This really is the case of a tempest in a tea pot that has boiled out into the general discussion. Stuart is a great guy, very bright, and was on a panel that was demanding. Okay, no big deal. However the inaccuracies came about, either through misconstrued comments and/or simply misspeaking on something, they are none-the-less inaccurate.

The first set of stories focused on whether or not MS is still committed to Open XML. It is - it will be - and we have never said anything different from that. Check out Gray Knowlton's blog as he is in the product team, and the group, that is working on this exact issue. We have always advocated choice in the marketplace, and yes - recently we announced that we would support ODF in Office. That does not mean we are stepping away from Open XML in the least. In fact, it is more of a statement of a deeper commitment to XML-based document formats...but that is a discussion for a different day. I'll leave the rest of this discussion to Gray.

The bigger issues come from the ZDNet article. Has Microsoft been working on standards before Open XML? Has the company done work on standards in the past? Will we work on more standards in the future? The answers are yes, yes, and yes.

Every big software producer works on standards as they relate to the products they are producing. There are essentially three scenarios on a given product. First, to implement a standard. Second, to work on a specification that is in process of becoming a standard. Third, to contribute a technology specification to a standards body so that it may become a standard. Microsoft has been doing all three of these across THOUSANDS of standards for decades.

More than eight years ago, a corporate standards organization was formed in the company to help product teams be better participants in standards orgs, to make more strategic decisions about what and where to contribute specifications, and how to deal with the legal issues surrounding standards bodies (there is an entire specialization in the legal field for this kind of work believe it or not).

Currently, the standards organization at Microsoft has more than 25 full-time employees in it and is focused not only on standards, but how the company thinks about interoperability and standards as a whole. What's more, because we are active in more than 150 standards orgs at any one time, and more than 400 overall - we have more than 600 product team and field employees who have been internally certified for standards work (and most of them are active in some committee or other). Our products have supported literally more than 10,000 standards and we have contributed specifications in the areas of development languages, runtimes, networking protocols, systems management, hardware, mobility, document formats, security,...the list goes on.

Anyone close to the industry knows that Sun, Apple, Microsoft, IBM, SAP, Adobe...any of the big players have people sitting in dozens to hundreds of standards organizations at any time. Companies in the hardware space like Toshiba, Sony, Intel, Samsung, Nokia, Phillips, Siemens...they have even greater standards engagement. There is a reason they are known as industry standards...it is because industry is the major factor in behind the investment of engineering resources to work on these issues. There is often close communication/collaboration with academia on standards-setting as well, but the big money and people investments are from industry.

I think it is very important that we take a step back from the self-perpetuating cycle of reporters and bloggers quoting each other to really think through what is being said. There are big differences in opinions about the role of standards, about the future of certain technologies, about the balance between IP protection and "openness," about the types of technologies that should be contributed...and more...but to work under the assumption that Microsoft (or any other big software company) is not committed to long-term investment in standardization is simply incorrect.

Strategic Use of Collaborative Development in South Africa - Follow Up

jasonmatusow — Wed, 28 May 2008 07:06:36 GMT

Last week I wrote a blog entry stemming from my experience in South Africa and my impressions about the way the OSS preference policy is being considered. What has come of it is a string of rather pointed comments questioning my intelligence and calling me quite the assortment of names - I though xenophobe was a particular low-point in the comments. Given the comments, it is worth clarifying my thinking and making a few points.

1) I think collaborative development can be extremely beneficial to South Africa. In fact, I think it should be a key aspect to their IT strategy for their eGovernment strategy. I simply don't think that discussion is limited to being about platforms. There is absolutely no reason that the agencies using any platform are precluded from using collaborative development to drive greater value from the existing ICT investments. To the extent that an agency is in the process of considering making new platform investments, then they should be free to look at all options and choose the one that provides best value for money over the long run.

2) I think technology mandates are not good policy in any country. In fact, I remember speaking at George Washington University a few years back and making this same statement. At the time, the Executive Director of the Free Software Foundation and the CTO of Red Hat both expressed support of that comment and that their organization's held the same view. Technology providers want their current and future technologies considered on the merits of the technology and the value those technologies bring to those who choose to consume it. If a government mandates a specific technology and/or class of technologies, they are unnecessarily restricting their own choices. Inevitably statue moves more slowly than technology, and mandates subsequently lead to sub-optimal choices.

3) My comments about the education of developers is a macro point and has absolutely nothing to do with whether those developers are in South Africa or any other country. I have no doubt that there are very talented Linux kernel developers in South Africa. Great - good for them, I think that is awesome. But it still doesn't answer the macro question about the types of projects that will both create high-value solutions and attract local participation leading to the in-country skills development that the policy is seeking to do. While I'm sure there is a subset of folks deeply interested in the core OS functions, there is a reason that a very small percentage of developers work on core OS development. I'd guess this is the same reason that there are relatively few operating systems compared to the literally millions of applications out there. Skills development is a good thing - I'm simply advocating that people look to the possibility that there is far more to collaborative development than OS coding.

4) I made a point in my last post on this subject regarding the opportunities for the creation of local software businesses based on OSS. Many, many governments are eager to see the growth of local software businesses. I am fully supportive of that intent, but don't happen to believe that OSS is necessarily the best model to bring that about. Economic opportunity is bolstered by having something unique. The most successful OSS companies have found a way to "hybridize" their solutions to in some way secure the uniqueness of their work while still tapping into the collaborative development community. Comparing the number of companies that have been commercially successful using that model with the tens of thousands of software providers using other development/commercialization approaches suggests to me that an OSS mandate is not likely to lead to the growth of local commercial software firms.

I was impressed with the people I met in South Africa. But I was also struck by the political realities of a technology mandate vs. the real-world opportunities open to them through a broader approach to collaborative development.

I was deeply involved with a series of projects that demonstrated a wide range of possible approaches to collaborative development (using non-OSS, OSS, and Free Software licensing models; using various approaches to tools, project types, funding models, etc.). Furthermore, I went through dozens of scenarios of thinking about core assets vs. complimentary assets and how OSS dev methodologies could be applied. There is so much more to the conversation than Linux vs. Windows. In fact, given the world of interoperability opportunities today, I'd argue that enterprise-scale environments are far better off thinking about "and" compared to "vs." and really looking at where the value to them from collaborative development is. Commercial implementations of enterprise-class operating systems are not free of cost. So - again, to me, the question is about how collaborative development can be used to extend the value of any platform decision.

Open XML, ODF, PDF, and XPS in Office

jasonmatusow — Wed, 21 May 2008 19:04:00 GMT

Clearly the Press Announcement today from Microsoft will bring about another wave of discourse on the future of document formats. The really short version of this announcement is that Office is going to support ODF, PDF, and XPS in the product directly and Microsoft engineers are going to join the OASIS working group on ODF, participate in the future of PDF in AIIM, stay active in the Ecma working group for XPS, and of course, remain active in JTC 1 SC34 where Open XML (and hopefully ODF) will be maintained over time. Also, when released, Office 14 will update the already substantial support for IS29500 in Office 2007.

While this is a big deal announcement for the Office product team (check out Doug Mahugh's blog), my take on it is predictably focused on the longer-term interoperability factors. Each aspect of the actions being taken by Microsoft fit into a very logical progression.

For years, I have vocally disagreed with the notion of a single document format as being the answer – the oft quoted Highlander line, “there can be only one.” My reason for this is very simple – document formats are representative of the innovation in the applications that use them. If you mandate a single document format – or even worse, a single version of a document format – you are effectively saying that you want to constrain application innovation to the limitations of a given format. I think this is bad news for consumers and producers of technology alike.

There is a continuum of thought related to interoperability reaching back many years based on the growth of Microsoft’s enterprise business, all of which has been affected by the regulatory activity in the U.S. and Europe. This is overlaying the real-world issues customers face as the world continues to progress toward network ubiquity and the desire to exchange an ever-increasing range of data electronically. In particular, governments are pressing hard to realize eGOV scenarios where they are seeking to effectively connect just about every type of information processing technology ever created. Thus, we end up in an ongoing conversation about interoperability.

There are some points to keep in mind when considering the news about the expanded set of document formats in Office.

This is not about any one document format “winning” – it is about enabling customers to evaluate and use document formats that make the most sense for them. Just as the MS deal with JBOSS didn’t mean we were saying that J2 was better than .NET – it is that we want our customers to have the most positive experience possible when using our product.
Nothing in this announcement removes existing commitments regarding document formats. Microsoft will continue to support the open source translator projects. Why? Because we started them in good faith with customers looking to use that mechanism to achieve interop, because other developers are picking up the platform agnostic projects and implementing them, because the collaborative development in the OSS projects has been educational for people on all sides of the interop issue. (Witness the work of DIN – the German national standards body – and their move to have those translation technologies become ongoing work in JTC 1 SC 34 WG6).
The Data Portability aspects to the Interop Principles will continue to move forward. For example, the API that will allow ANY document format to register itself with Office and be set as the default will be made available as planned. Additionally, the work with DAISY and other specialized document formats will move forward as well.
The documentation of client/server protocols for Office-related technologies (such as SharePoint and Exchange/Outlook communications) will remain available to the public.
Microsoft will continue to listen to customers about specifications’ version numbers and look at the practical nature of software implementation as we make decisions about what to implement. Office is NOT implementing ODF 1.0 from ISO. That spec is not representative of the marketplace today, it is not what is implemented in OpenOffice, it is not what IBM is using for Symphony, and it is not referenced in the Massachusetts ETRM policy. We are looking carefully at the business, customers, marketplace and competitive issues for each of the specifications and the MS implementation work will depend on those considerations.
Participating with quality engineering capacity in Open XML, ODF, PDF, and XPS working groups will pay dividends for our customers over time. I know that the skeptics are going to spin theories about MS participation in these groups – but the reality is that we want the specs to continue to improve over time and facilitate interop so that our customers are happy with the value they receive from our solutions. Clearly product competition is always a factor in this discussion, but that is the exact reason standards bodies exist – so all parties (even direct competitors) have a neutral forum in which to work on specifications.

The next 12 to 24 months are going to be extremely telling in the world of document formats. The myopia around the standardization process of Open XML will fade as software producers continue to invest their development budgets in the creation of solutions. The specification itself is only the start; it is the implementations, and the competition in the marketplace of broader solutions that will continue to matter more. In my opinion, the continued interest in innovation presented by those solutions will speak much louder than the formats themselves.

The Politics of OSS Still Overshadow The Benefits of Collaborative Development

jasonmatusow — Mon, 19 May 2008 22:33:14 GMT

It has now been almost three years since I stepped away from working daily on open source opportunities for Microsoft. I've watched the team that took on Shared Source morph it into some extremely positive collaborative work that is exactly what OSS is all about. The paltry few projects that were in place in 2006 have blossomed into thousands of projects, and some of the core source release programs for flagship technologies are still operational today. All good.

Unfortunately, I can't say that I'm seeing the same understanding about collaborative development when I go out and meet with customers, governments, partners...whomever.

I haven't been blogging much due to a great deal of travel, and the huge backlog of other work catching up to me following the close of the Open XML process. One of my most interesting trips was down to South Africa to talk interop, document formats, and yes...open source software.

South Africa has taken a most unfortunate position of late - the government has sought to put a political mandate in place for the adoption of open source software. I am against all technology mandates, and this one is no different. Ultimately, it constrains decision-making away from technology, solution quality, ROI on existing investments, people issues...in short value-for-money - all in the name of a political position. Worse, it is pushing CIOs into decisions that they don't want to make - essentially taking working environments representing huge investments and moving to untested, more expensive solutions.

But, the most serious issue to me is that they are not looking at the real benefits that OSS can bring them. Politically, every conversation about the OSS mandate is really a Windows vs. Linux discussion. This is in no small part assisted by the local presence of Ubuntu. There is absolutely no comprehension that the Linux they will deploy on an enterprise scale will be completely locked down by commercial services agreements and version controls by the apps vendors (e.g. SAP). This is absolutely fine from a decision point of view for enterprise systems, but it is most certainly not any gain due to open source.

The real value of OSS to a government that is looking to:

save money
bring development skills in-country
address local issues with home-grown, customized solutions
gain operational as well as financial efficiencies across government agencies
foster local services and ISV opportunities
etc. etc.

is to apply OSS development and licensing methodologies at the app-dev and tools layers, rather than thinking of the core OS as an OSS opportunity for them. Deep dev of the core OS is not likely to happen in South Africa today on any large scale. Students at the university still grappling with coding skills are not going to dive into the inner-working of Linux. Any innovation on Linux that is broadly applicable will immediately be picked up by Red Hat or Novell and commercialized globally with little economic benefit coming back to SA.

Yet, if they looked instead at the existing investments in infrastructure, and thought about the use of OSS against the custom needs of their government activities. Or for intra-government projects. Or for building key bridges to enable eGovernment solutions. Or any of a number of projects - they could bring in academics, local ISVs, local services providers, engage existing government developers, etc.

All of that could happen regardless of whether the platform is Windows, Linux, AS/400, OS/X...whatever.

The developing world still views OSS as "free as in no money," and that is widely known to not be the case. Technology solutions are expensive no matter what the development and/or philosophical model are underlying them.

I heard this same point of view for 5 years all over Asia, parts of Europe, and Latin America. I saw governments try to incubate OSS businesses solely because "OSS" was in the title and mandate. Then, those businesses failed, and the mandated solutions turned out to be far more expensive than other commercial alternatives. Almost uniformly this came about through a misunderstand (in my humble opinion) of what OSS can do for organizations.

There is a reason that Harvard Business School found that more than 95% of all OSS venture funding went into fewer than 20 projects. Those heavily commercialized projects are just another way to deliver high-value, mass-consumed, supported technology. Finding the value of OSS beyond those projects for the average organization is all about applying collaborative development against real-world problem sets in small, efficient projects.

Ahhh...it feels good to blog again. :-)

Participation in standards...

jasonmatusow — Wed, 23 Apr 2008 07:18:25 GMT

Just a quick note today. I am on the road meeting with MS people and later this week doing a bunch of external outreach work in South Africa as well. During the last few months there has been a good deal of rumblings about participation in committees, about countries moving from o- to p- status, etc. The more I ruminate on this, the more I think people are missing the point.

Standards are supposed to be inclusive rather than exclusive in nature. The increase in participation during the past 12-18 months is positive overall. Even more so that some countries with emerging economies chose to elevate their status in either SC 34 or JTC 1.

I've been spending some time talking to folks in some of these countries and have found examples of places where the political decision to move to p-membership was to amplify a yes vote and elsewhere to amplify a no vote. While certainly within the constructs of the rules, my personal take is that is not a great reason for the elevation of status.

But, in every other case I've looked into, the governments are genuinely looking to increase the footprint of ICT work in their countries. They are looking for opportunities to be more involved in the international ICT discussion. I think that is extremely encouraging.

As many people continue to ruminate on the state of standards following the adoption of Open XML, this topic should take a prominent position. The fact that so many people had opinions on the standard, and were willing to participate to even the most minor level (letters sent in, vs. attending meetings etc.) all the way up through attending committee meetings and traveling to the BRM etc. had a real impact on the process.

Many of the most developed nations' national standards bodies have dedicated at least some resource to capacity building for emerging countries. Furthermore, finding a way to address the idea that international standards take such heavy financial and people resources has merit as well. For example, I found out that in Australia the coal industry uses a blind trust mechanism from industry to enable participants to work on ISO standards - even if they are from smaller firms or academia where travel budgets can be very hard to come by.

Food for thought for sure.

IP, RAND, Standards, OSP, ISP - the conversation continues...

jasonmatusow — Sun, 20 Apr 2008 03:14:00 GMT

There have been numerous comments to my last blog posting, as well as a long response from Groklaw. Overall I am encouraged by the conversation as a whole because I think it is touching on some foundational issues.

One of the most challenging aspects to the threads I've been reading in the responses to my post (and I see this in the Groklaw post as well) is that many issues are getting squashed together - and that is the very basis of misunderstanding these issues. One more thing, there are a few people who put some really excellent stuff in the comments to my last blog post, and I recommend them as reading. Andy Updegrove’s comment is probably the most thoughtful and thought provoking of the lot.

I’m going to try to pull out some of the most commonly touched on points and themes. This is long...sorry.

Standards and business models

At the core of the discussion both on this blog and over at Groklaw is the question of how evolving business and licensing models blend with the existing standards world. The fact that Free Software as a concept has been around since the mid-late ‘80s (if I remember correctly) is not particularly germane. It was really only following the massive commercial investments of the early 2000s that we see the growth of some very fundamental issues in software business models. (I know there was significant dev work happening in the 1990s – but this is a meta point about the industry.) The hockey stick effect of OSS adoption and real business momentum has brought about the discussions about RAND, GPL, covenants not to sue, etc.

You will get no argument from me on the point that the adoption of FLOSS in big business and small are changing the face of the software industry. But by the same rational point of view, the growth of the overall software industry continued to be fantastic during that same period of time. My concern has always been with people who argue that because the Free Software approach is predicated on certain beliefs, and that it is being used, that everyone should have the same beliefs. I think it is ultimately unhealthy for the industry for everything to shift to a single approach – we are all better off with choice of business models, choice of licensing models, and choice of solutions to acquire for addressing business needs.

(Caution – major simplification here) Standards bodies are meant to be the place where all parties come together in an environment that is safe and beneficial for all participants. And where even those who were not involved in the process, may utilize the output from the process in a safe and beneficial way. Additionally, it is in all parties’ best interests to see sustained contribution of innovations into the various standards orgs (no matter what model they were developed under). Moreover, it has been considered highly desirable to have both standards and solutions compete in the marketplace which pushes innovation and opportunity even further.

So in the discussion of RAND and GPL and even in the case of Open XML and the OSP – I think it is worth considering how it is that GPL implementations may be done. But I disagree if the argument is that they should be done regardless of any consequences to those who do not share the same model. There are ways of building bridges between models – to me, that is the most important place to start.

Free Software Licensing and RAND

I do not want to belabor this point. Groklaw pointed out, as have many others, that Free Software licensing conflicts with RAND. Not just on royalty terms, but on sub-licensing and limitation of scope as well. This is not the end of the world, nor is it a show-stopper (obviously – Unicode, for example, is shipped in Linux I believe). So the question then becomes how do software producers who have an interest in seeing their technologies broadly adopted (even in Free Software implementations) find ways to bridge the gap. Of course, it would be good to see the Free Software community seek to meet in the middle with all parties – consensus helps (IMHO).

ISO and RAND vs. Terms From Vendors

Throughout the comments people are still saying that the JTC 1 RANDz declaration for Open XML is somehow different than other JTC 1 RANDz declarations. It is not. The same rules apply to all specifications – uniformly. ODF and PDF and others are under the same terms. The assertion that Microsoft could somehow “wield” the JTC 1 declaration in a means different from any other contributor to an ISO spec is false. What’s more, the Open Specification Promise goes significantly further than the JTC 1 RANDz declaration and was created to enable the full spectrum of implementations. (Notice Gnumeric has included Open XML support even though it is GPL licensed.)

Vendor Promises – OSP/ISP/CNS

The vendors who are making promises, or covenants, on their IP separate from the terms directly associated with the specification are doing so to build the bridge I spoke of earlier between the traditional IP-holder structures and the Free Software model. We can (and probably should) debate the merits and drawbacks of each of these, but you should first take a step back and recognize that these promises are a positive step in the direction of enabling the highly divergent licensing models to coexist. It is also important to note that while a few of the big players have taken this step (logical because they are the ones holding more patents or who have more directly involved product interests), it is not common practice in the software industry. There are thousands of rights holders who participate in standards, whose contributions merit great respect, and who wish to maintain control of their intellectual property. For smaller software vendors whose business model is dependent upon the direct commercialization of their software, a mandate to exhaust their patent(s) (forget royalties – there are other issues worth considering here) will act as a disincentive for contribution.

Is the OSP from Microsoft global?

I saw this questioned a bunch of times so I think it is worth clarifying. The OSP is a global promise – to everyone, in every country, and in every line of business or personal interest. People are confusing whether or not there is legal recognition of software patents with the reach of something like the OSP. Those are different concepts and worth separating in your thinking.

Should standards orgs change their policies to accommodate free software?

This is a decision that each and every one of the hundreds of standards organizations who handle software standardization will need to consider. There is absolutely nothing inherently bad about working with it or not – it is a choice based upon the charter and membership of that organization.

In many ways, my answer there is a punt, but it is true. My opinion is that effective bridges need to be found, and done in such a way that things remain fair for all parties. Companies that sell software directly must clear their product for patent royalties and other IP considerations before selling it into the marketplace. The standards bodies have IP policies so that their output too is copasetic in regards to IP before people begin to use the specifications (thus the concern about trolls). There is no reason that orgs commercializing Free Software should not respect other’s IP as well.

I think an interesting way to consider this is to take a logical extreme of the argument – what if every standards body mandated Free Software-compliant (not MPL, not EPL, not MsPL...only GPL) licensing terms. What would happen? Some might say we would be one step closer to nirvana as a race. Some might choose to drop completely out of the standards game and seek individual licensing agreements and/or cross-payments etc. to bring their product to market with interop features. Certainly there would be those who would be forced to fracture their product (again, good/bad...all depends) and ship some components separate from others to stay compliant with the source license. Others might pursue a whole raft of SIGs (special interest groups) that are exclusionary and outside of the standards world. Still others...I could go on. To me, that is not a good outcome. I think we are in a better state if standard bodies continue to serve their purpose and be a place with highly competitive parties can come to the table to collaborate on specifications even if they have diametrically opposed business/licensing models. Ultimately, the marketplace will speak louder than licensing mandates.

Should there be multiple licensing schemes?

This is an extrapolation on my part from what I’ve been reading in the comments of my last blog. I’ll first say that it is a moot question because there are and will be multiple licensing schemes. How many OSI licenses are there? And why is that? Because IP holders all have strong opinions about how their IP should be handled. Secondly, I am always a fan of choice...and am nervous when zealotry begins to suggest that any alternate choice is heresy. This leads to a very scary place.

Conflict of reciprocal licenses – was I speaking correctly?

I spoke of the fact that Linux ships with code that has conflicting licensing agreements. And many people asked me to “prove” it. I’ll let you all tell me if I’m nuts. All reciprocal licenses by definition conflict with each other. The GPL claims to cover the “aggregate” product, the CPL/EPL the “component,” and the MPL the “file.” In all cases though, if there are conflicting terms they all say you can’t distribute. So – is there any mingling of GPL, MPL, EPL code in Linux? How about the rest of the licenses purported to conflict with the GPL?

By the way, this is also true for the point that I made about RAND terms on code shipped with Linux today – how about Unicode for example? Last I check, IEEE 1394 Firewire was similarly licensed. There are literally THOUSANDS of RAND-covered specs out there used commonly in operating systems throughout the industry.

Now, on to the leap of faith on the part of my critics – I did not raise this point to spread FUD about Linux. Why can I say that? Because this point has been raised in public events in the past...and it continues to not matter. So my point is something else entirely.

Legal snags like the ones I mentioned only matter if someone presses it in a court case. No one can say if these issues will ever become an issue but that has never stopped a single person from using Linux. So, when people then say that the MS OSP, or IBM’s ISP, or RAND terms, or whatever means that Free Software developers can’t develop something, I find it hard to take seriously when the intent, and all of the materials surrounding these actions speak of building bridges and enabling...not shutting down or threatening. Those same developers are willing to take those exact same issues as no concern on one hand and then scream foul on the other. It’s worth thinking about a bit.

Ending this long post...

Too much here already – thanks again folks for the good comments. We are at an inflection point in the industry...and that is exciting to be a part of. If you are going to comment – let’s shy away from the zealotry, and stay focused on lucid arguments.

More Open XML Discussion - more misunderstandings about standards and IP

jasonmatusow — Wed, 16 Apr 2008 05:28:58 GMT

There is much to talk about based on what has been happening in the discussion of Open XML these days. First, ISO has posted a FAQ about 29500. The approach taken in the FAQ is both direct and simplified. The rabbit hole on standards goes deep indeed, and any such FAQ must simplify to make it digestible for the layman reader.

An example of someone misunderstanding standards and IP issues would be Groklaw in this post. The post displays many of the misunderstandings about IP in standards that I see echoed around the blogosphere.

I will say that the author of the Groklaw post got it right when they wrote that, "Patents and Linux and FOSS don't mix." But the author jumps off the tracks completely when the observation is followed up with, "So RAND terms in Microsoft's hands are discriminatory."

I think it is important that anyone offing an opinion on the OSP should first ask him or herself a question: do I really understand IP licensing in the world of standards? I'd suggest that the author the Groklaw post didn't ask this question up front and would benefit from some boning up - it would help get the story straight.

Here are some things I think may be helpful in this discussion. By the way, my answer to the question I just posed in the previous paragraph is, "sort of."

1) RAND (reasonable and non-discriminatory) did not originate with software. It is a commonly used acronym but has different meanings in different standards bodies. It has many parts - more than just patent rights, more than royalty terms...my understanding is that it is a framework designed to provide both incentive for contribution and implementation. The reason I agree with the statement about patents and Free Software not mixing is that there have been terms written into GPL licenses that explicitly conflict with software patents. Okay, that is the choice of the authors and users of those licenses. But the fact that those licenses were written does not mean that the RAND terms that have evolved over the past century of standardization are suddenly invalid.

2) The ISO/IEC JTC 1 patent policy is applied uniformly to all standards in the ISO/IEC JTC 1 arena. The idea that the RAND declaration regarding Open XML is any different than a RAND declaration for ODF or for any other ISO Standard (such as...oh I don't know...how about PDF just for fun. Remember the huge list of patents that Adobe used to put on the welcome screen of the Acrobat reader alone?). The terms provided for the Microsoft patents in Open XML are legally irrevocable. They are global. Since they are broader than the RAND declaration for JTC 1, the attempt at FUD by the Groklaw post should be recognized for what it is...FUD.

3) The various covenants not to sue or similar promises from a few (mind you, this is hardly common practice in the software industry today) of the big vendors are all born of the same desire - to help bridge the gap between Free Software and software patents used in specifications. Forget the philosophical and ontological debates about software patenting for a moment and just deal with the fact that the law in a number of countries recognizes software patents as valid IP today. And, judging by the continued pace of patent filings, it would seem that more than a few people out there are seeking to use software patents as a legitimate means for protecting their innovations. Heck, even some of the long-time Free Software advocates are looking at the positive implications of patenting software as a means to encourage greater innovation. Yet all of these bridges run into some snag or another on various points. So the question that comes to mind is how important are those snags?

Before you get your hair in a knot over this, consider for a moment that all Linux distributions come with code licensed under reciprocal licenses that conflict and (in theory) should block the distribution of the software. Oops, no one seems to care about that snag. Okay, Linux also ships with code that implements standards specifications covered by RAND terms from many parts of the industry that should block the distribution of the software. Oops, no one seems to care about that snag either. Hmmm - I'm wondering if those complaining about the OSP understand the nature of IP terms in standards to begin with, since they don't seem to mind these other, potentially more-serious issues.

4) Many of the terms included in standards IP licensing are there for a rainy day vs. for any practical use. In many cases, IP holders will provide RAND terms that include royalty terms yet never, ever collect a penny in royalties. Why, you might ask? Those terms are there as a defensive mechanism. This is true for the entire concept of defensive suspension and to a large degree the concepts around limitation of scope as well.

5) The concept of "discrimination" in the standards world of RAND is another one where you really need a lawyer to talk you through what it means and/or doesn't mean. I am not a lawyer, but to my understanding it has a great deal more to do with the uniformity of your application of terms to like parties than it has to do with any one party being able to take those terms or not. If there are lawyers reading this thread I'd love the input. Everyone should have the choice of what license they use - but there may be implications for the use of those particular terms as they will interact with the rest of the world.

Concluding this too-long blog post...

As you can see, looking at the real issues on the table about IP and standards is a good thing to do. I am on board with the idea that the established world of IP in standards needs to be looked at carefully in context with the amount of work happening under the concepts of reciprocal licenses. It would be helpful if folks who speak with a loud voice also seek to do so in an educated fashion.

I am a serious proponent of participation in the process - but that needs to be for all parties, large and small alike. But that means keeping an open mind while you are also advocating open standards.

Open XML - SC34 Maintenance Agreement

jasonmatusow — Thu, 10 Apr 2008 21:33:40 GMT

Throughout the months leading up to the BRM and then following it, there was discussion over the future maintenance of the specification. Rather than recapitulate the results of the last SC 34 meeting, let me just point you to Alex Brown's blog. For those of you who were not following all of the players so closely - Alex was the convener of the ballot resolution meeting.

I still hear patently untrue claims that MS controls Open XML - this wasn't true following the adoption of Ecma 376, and is now permanently a moot argument. Alex's blog title says it all:

ISO COMMITTEE TAKES FULL CONTROL OF OOXML

Does anyone know if the commercial interests in control of ODF would be willing to take the same step?

Texas Legislature - Electronic Documents Hearing

jasonmatusow — Wed, 09 Apr 2008 05:29:58 GMT

On Wednesday April 9, the Texas House of Representatives Government Reform Committee will be hearing testimony regarding electronic documents.

The notice for the hearing states that the committee is looking to hear about:

Research, investigate, and make recommendations on how electronic documents can be created, maintained, exchanged, and preserved by the state in a manner that encourages appropriate government control, access, choice, interoperability, and vendor neutrality. The committee shall consider, but not be limited to, public access to information, expected storage life of electronic documents, costs of implementation, and savings.

Following last year's multi-state lobbying campaign to enact hard procurement preferences through legislation of mandates for ODF, I am expecting that the same tune will be sung by IBM, Sun, Red Hat, and Google. If they choose to go down the same path of advocating a single format (ODF) rather than taking the time to listen to their customers, it will be a reminder of their single-minded drive to use document formats as a competitive wedge for their products rather than for meeting their customers' needs.

In every single state where there was a hard preference discussion, governments opted to look for first principles appropriate for codification in statute rather than using their legislative powers as a means to pick winners in the marketplace. MA, TX, MN, CT, CA, OR...and not just in the US. This was true all over the world.

First Principles:

The most basic frame for the discussion of electronic documents is simply that all states are seeking to accomplish the provision of services through the use of technology while obtaining the greatest value for money. Within that context the State wants to address the needs of communication with constituents, transacting government business, implementing effective archival policies…all based on the efficient use of resources (people & dollars).

A) Within the context of document formats, constituents want to communicate with the State using many formats – older binary formats, newer XML-based formats, non-modifiable formats, web formats, specialized industry formats (e.g. insurance, healthcare, financial services, etc.), etc. etc. The State will not mandate what products or formats their citizens use.

The best option for the State is to apply a first principles approach that focuses on the top-level goals while leaving maximum room for innovation and competition. For document formats, this would mean establishing statute that says any procured solution must provide effective support of document formats that enable communication with constituents. The State does this today by making information available and receiving information in PDF, DOC, HTML, ODF, Open XML, etc. etc. – any advocacy for going to a single format preference seems to counter the first principle for communications.

B) Transacting government business is based upon applications…not document formats. The apps are the tools used to solve business problems such as the production of complex documents, the manipulation and calculation of information in those documents, etc. This is the crux of business competition from the vendors represented in the hearings on Wednesday. The State should desire greater competition among the vendors to drive innovation and value in the solutions available to them. In fact, this is the exact argument that IBM, Sun, Adobe and others are suggesting - but their approach is flawed when they seek to accomplish this by limiting choice rather than promoting it. (Check out Enderle's post - good points by him on this front.)

If the State were to legislate a single format, they are effectively creating an innovation dead zone by limiting the features / functionality of the applications to the capabilities of a single format. Would IBM and Sun suggest that no state support DAISY? Or the National Library of Medicine formats for research papers? Or PDF for posting of public document for public viewing? ODF (using the generic here on purpose) itself has already progressed beyond the 1.0 ISO version because of the need for the format to represent the innovations in the products that use it. The State of Massachusetts looked carefully at this issue and decided the best path was to set policy at the first principles level and focus on open standards, not on picking one standard over another. This leaves the CIO(s) of the State open to make choices based on value, functionality, and whether or not the products purchased meet the first principles rather than meeting an arbitrary technology mandate.

C) Archival continues to be a critical discussion for governments. If there is any place where first principles are crucial - this is it. The first principle for the State should be one of saying that any solution chosen for office automation technology should provide support of the State’s archival policies and procedures (already defined elsewhere). This includes preservation, access of the data independent of any application, translate-ability of the data from the original format into another, scheduled destruction of the data based on statute, the ability to set custom schema within the context of open standard specification, etc. Then, the CIO's office should be evaluating all solutions against these principles and making the best value for money decision to achieve the stated goals. If done properly, this is an example of using first principles in statute to enable the maximum amount of competition and choice between solutions.

Interoperability:

The last thing I want to point out is that the committee hearing is really about interoperability - JUST LIKE Massachusetts ultimately focused on in their ETRM policy. The marketplace reality is one of multiple document formats. So the question is about translation, it is about building a bridge between formats. It is about dealing not only with the different formats, but about the multiple implementations of the different formats.

If I were in the hearings, I would inform the committee of the work that DIN (the German national standards body) kicked off with the Fraunhofer Institute and their SC 34 mirror. If I am not mistaken, this is also part of the SC 34 committee meeting discussion in Oslo where they are thinking about interop between Open XML and ODF as well. At the international standards level, the issue of interoperability is being pursued. Moreover, there are now hundreds of implementations of Open XML, there are similarly numerous implementations of ODF, PDF (at least in output) is supported broadly...so interop is really the name of the game.

Many of the states who were considering mandates last legislative session ultimately decided to kick off study projects to further consider this issue. I do hope that these studies take a long-look at what really matters, where the value is, and how interoperability will work in a multi-format world. The single format argument is a red herring argument.

Open XML - Where The Rubber Meets The Road

jasonmatusow — Tue, 08 Apr 2008 05:21:28 GMT

After so much prognostication about standards in the abstract, it struck me today that it's worth taking a moment to look at Open XML through a different lens. Does it make a difference for people who are using it? Is it doing what it was supposed to do?

I'm going to step away from the tit-for-tat debates and simply point to a few examples of where Open XML is helping to solve real-world issues. I believe that whether or not a specification is relevant to the marketplace is a crucial factor in determining its value as an international standard.

And before anyone gets their hair in a knot - I'm sure you could post logos of people using ODF - fine, groovy for ODF. If that is what you see from this list, then you are missing the point. I have always advocated choice in formats...and will continue to do so. For Open XML - no matter what other formats are out there - the real test is in whether or not it is used by organizations to meet the challenges of their business. Period.

[note: each of these is linked to a case study about how Open XML is helping their org.]

I picked these up from www.openxmlcommunity.org. There are even more at www.microsoft.com/casestudies.

van den Beld Post & Participation - Open XML continued

jasonmatusow — Fri, 04 Apr 2008 18:09:00 GMT

The complaints keep rolling in on Groklaw about the outcome from Open XML. ***UPDATE #2: I went out to dinner and have been thinking a great deal about this. I do hold an opinion on this, but I think it is reasonable that people who read my blog expect me to be careful with my assertions. For that reason, I retract this statement.***~~Strange that a website setup by IBM to fight a proxy war during the SCO case would be so focused on the Open XML discussion today. But that is for another day.~~ ***UPDATE: Concern has been raised in the comments of this blog about my assertion of Groklaw and its contents. My assertion in the preeceeding paragraph is my opinion - take it or leave it a face value please.***

It may be that the disagreement of opinions following the approval of Open XML has exceeded what was happening during the process. The one thing that I have noticed from the anti-Open XML camp is a myopia when it comes to facts. It's amazing to me the capacity to put up blinders to facts that skew the picture away from their world view. ***Update. In thinking about this paragraph I think it is worth noting that Microsoft (as with any organization) should take to heart concerns raised about Open XML so that our engagement in international standardization work continuously improves.***

In light of those blinders, it is worth your time to look at a blog post from Jan van den Beld. It is an educational post. If you don't know who he is, he was Secretary General of Ecma for many years and a long-time participant in ISO/IEC business. In fact, he was there at the start of JTC 1 and has been such a good participant that the latest version of the JTC 1 directives are dedicated to him personally.

Participation:

This brings me to my thought of the day. One of the most often raised accusations of the community who was in favor of Open XML was that they were "stuffing committees." There are a number of things that come to mind when I read these accusations.

Participation is a good thing - it is a very positive word and concept. Furthermore, it is an important part of the standards world.

Yet in the case of Open XML, it seems that participation by those in favor of Open XML only happened through pernicious activities and breeched ethics - while participation against Open XML was purity and light personified. I just don't get that.

In Norway when IBM and Google join the committee 2 days before the final vote...or when IBM brings a subsidiary company to the table with them in Italy effectively giving one company 2 votes...or when Oracle and Red Hat join the US V1 committee just before it votes....that is participation, right? I actually believe that to be true. It is no different than Microsoft or its business partners coming to the table to have their voices be heard in the process. As long as the participation is within the context of the rules for a given NB, then it is legitimate participation.

It would be nice if people would get off their high-horses on this particular issue, because the only position ANYONE should be taking is one in favor of participation. I would certainly be surprised to hear that anyone thinks participation should only be limited to those who agree with you. That would be an indefensible position to take.

The Process Challenge - A Predictable Path

jasonmatusow — Wed, 02 Apr 2008 03:49:00 GMT

***Updated April 7, April 8***

In light of the approval of Open XML as an international standard (see the ISO press release here), there are a few countries in which process issues are being raised. This blog post will act as repository of the challenges and information about each of them.

For the past few weeks I’ve been saying that no matter what the outcome of the Open XML standard work, the specification would be improved and that was good for the industry. As an ISO standard it moves to SC 34-led maintenance and continues to see significant take-up via independent implementations and extension of existing implementations. If it had failed to become an ISO standard it would continue with Ecma TC 45 maintenance and they would decide how much of the post-BRM spec to adopt into the Ecma spec – and it would continue to see significant take-up via independent implementations and extension of existing implementations. Of course all of this is in light of the fact that if you don’t like the specification….then you don’t have to implement it. (I have always been opposed to technology mandates.)

What has remained consistent during all of this is that product competition between MS Office, OpenOffice, Lotus Symphony, GoogleDocs, Acrobat, WordPerfect, etc. etc. etc. has remained firmly in place. Just because IBM is implementing Open XML (which they have announced) and ODF (proving my point about multiple formats) – they will still argue that their product offers greater value than everyone else’s product. Good – and each of the other vendors will do the same.

Industry participation has been driven by commercial interests – essentially acting based upon their own analysis of what they think their customers want from solutions acquired from that vendor. Everyone needs to take a step back and remember that having commercial motivations both in-favor or against the adoption of Open XML as an international standard is a good thing and is completely normal in standardization. It is completely legitimate for companies who are Microsoft partners (or who have an independent interest in using the specification) using Open XML in order to deliver functionality to their customers to participate in the standards process. They choose to invest engineering and business resources in support of Open XML as a means of supporting their own business interests. This is just as true for a business partner of IBMs (or who have an independent interest in document formats) who joined big blue in the work against Open XML because they felt it was in their best interest to do so. Standards work is meant to be inclusive rather than exclusive.

Following the ratification of ISO/IEC IS 29500, those with commercial interests who have opposed Open XML are now pressing a concerted process challenge which is to be expected. Strangely enough, it is ultimately healthy that they are doing this, but I think it is important to look at this next step in the Open XML saga.

The Process Challenge

It is common in litigation that after a decision goes against a party, one of the first things they look to in their appeal is to challenge the legal process itself (and the actions of their opponents) rather than the merits of the case. This is usually because the arguments made regarding the merits of the case resulted in an unfavorable outcome. So, they go after the process itself in hopes of getting an appeal heard and ultimately to turn the decision in their favor.

Ultimately, it is better for the system to have this avenue of appeal always remain open. It means that “the system” (in whatever context you are talking about) has hygiene built into it. It also means, that if the rules were not followed, that the parties involved need to be accountable for their actions. However, you have to make your case that your appeal has merit under the applicable rules and regulations, so attacks for the sake of attacks don’t achieve much beyond generating sound and fury that signifies nothing.

So we find ourselves in this situation with Open XML. IBM/et al worked very hard to oppose the Open XML standard. They committed millions of dollars to the effort, lobbied hard, worked with their partners, but did not get the outcome they were hoping for. The thing that makes the world of standardization different than litigation is that working on a specification (as supporter or critic) results in the specification getting better. IBM was the #1 contributor of comments worldwide. In fact, they were so pleased with their comments that they made sure they were replicated and echoed from national body to national body. In some countries, IBM was responsible for more than 90% of the submitted comments, and everywhere they added essentially the same comments to their work in national bodies. They got their wish – their comments, indeed, 87%+ of all comments, were resolved in the disposition process and the national standards bodies felt that the process had been successful. The standard had improved, and many of them modified their votes (completely in line with the goals of the BRM process) in favor the specification. Ultimately over 85% of all voting countries approved IS 29500. Comments that may not have been addressed during the BRM to a participant’s satisfaction, or any other issues that national bodies can think of going forward, can now be raised in the maintenance process that will be established under ISO/IEC SC34 control. That’s exactly how the system has been designed to operate so that specifications may continue to improve over time.

We now see IBM/et al driving an orchestrated process attack in the hopes of overturning the ratification of Open XML, or at least to discredit what has come out of this long, global process. While I certainly hope they are not successful in this attempt, I do respect the right of anyone to raise questions about the process. National standards bodies have been saying that they voted in favor of the standard because of the importance of the technology, the fact that the process was successful, and particularly the fact that the comments that they submitted (meaning the issues they cared about most) were satisfactorily addressed (properly within the process) during the BRM process.

If there are aspects to the JTC 1 process that need to be changed (and there are some aspects that could be improved to help all future standardization), then that will occur through the mechanisms allowed for the modifications of the JTC 1 directives. Ultimately, the lessons learned from the unprecedented activity around a single specification will be good for JTC 1. We look forward to being a part of a productive dialog about what modifications, if any, should be made to the JTC1 directives so that it can be well prepared for the future.

***Updated*** Anticipating that these process challenges will continue, I will collect information on my blog to help people put the big picture together. To be clear, my belief is that the overall process leading to the ratification of the standard was solid - and that it is extremely unlikely that the result will be changed due to the issues being raised by those opposed to Open XML. I will keep updating this blog post over time. It is not my intent to speak for the national bodies, they will make their own choices about what to say regarding the adherence to their defined processes. The same is true for ISO/IEC (parents of JTC 1).

At the end of the day, a successful procedural challenge needs to walk a fine line between rational debate and personal insult for those responsible for the process. Casting aspersions on respected members of the standards community is not the best way to achieve change. The community attacks on folks like Patrick Durusau (toward the bottom of the screed) are ridiculous. The personalization of the process claims by IBM fall into a similar category in my opinion (if you haven’t seen Rick Jelliffe’s post in response to a Bob Sutor post – it is really worth the read). The outright attempts of character assassination on respected standards professionals around the world by some of the more acerbic voices in the blogosphere are extremely distasteful to me. (Apparently this is true for others as well.)

From the Microsoft perspective – we are going to be part of the international standards community for a long time to come. In the past our participation was not as consistent as it should have been. There is no question that international standards will likely increase rather than decrease in importance over the next few years. My sincere hope is that the global community both moves on to work on achieving interoperability between document formats in the market (more on that in another blog posting) and works to understand what the Open XML process can teach us about how standards development efforts in the rapid development/innovation environment of information technology should be undertaken going forward.

****************

Country: Germany

Criticisms: NOOOXML, Groklaw, Updegrove

Response:

The following statement comes directly from DIN – among the world’s most respected standards bodies. [English Translation]

Current reports in the Internet, on the decision procedure in the DIN committee on ITC with regard to ISO/IEC DIS29500 are wrong and misleading.

The vote in the working committee responsible for the expert evaluation on ISO/ IEC DIS29500 has been cast on March 11^th. The question was whether the -vote “yes with comments” from September 2007 should be maintained after the insights from the ballot resolution meeting or should be changed to a “No” vote. This was a vote of the experts in the working committee. DIN as such had no vote in the working committee.

This ballot has approved ISO/IEC DIS 29500 with 15 to 4 , this has been correctly reported from non authorized sources. The experts in the working group have voted. DIN as such doesn’t have a vote in a working group.

The steering committee did not have the mandate to review or lift the expert decision. This is not its responsibility. The only question to decide was whether the ISO process has been flawed with regard to formal criteria according to the opinion of the steering committee. Because the decision of the steering committee did not deal with technical issues but with the rules of the JTC1 fast track, i.e. with compliance issues with the rules DIN saw a need to take a position. Therefore the DIS employee took part in the voting and did not abstain as he would in technical issues.

On March 27^th the voting members of the steering committee on ICT standards had to vote not on the acceptance or non acceptance of ISO/IEC 29500 as standards but on the compliance of the process. The steering committee has accepted the process to be compliant and therefore seen no reason to lift the yes vote of the working committee. The steering committee has accepted the process as compliant with the rules with a majority of 7 to 6 and therefore it has seen no reason to lift the decision of the working group. If the majority of the working group would have been convinced that the process of dealing with and voting were non compliant to the rules then the German vote would have been changed to abstain.”

***Update***

Here is a press release from Fraunhofer FOKUS - with quotes from the chair of the DIN SC 34 mirror committee, Gerd Schurmann.

Once again the international collaboration of experts from different countries within the framework of the ISO has proven to be a suitable forum for the development of international standards that can also meet market timeline demands through cooperation with other standardization organizations like Ecma and OASIS.

***Update***

This is the English press release from TÜV, a respected German institution. Their statement is in favor of the OpenXML ratification by ISO and supporting the ISO and DIN processes. TÜV NORD Group (http://www.tuev-nord.de/), with its staff of over 8,000, more than 6,300 of whom have technical or scientific backgrounds, is one of the biggest technical service providers in Germany.

****

Country: Norway

Criticisms: Groklaw, Groklaw, Geir Isene

Response:

Standards Norway has released a statement - here is the English version in PDF (note: the translation I had up before was not the official English version. I have pulled that text from the blog in favor of the doc from Standards Norway.) Standards Norway has provided a very thorough discussion of the process leading to their decision. It is worth reading.

This was supported by coverage in the International Herald Tribute, and the NY Times. Ivar Jachwitz, deputy managing director of Standards Norway is quoted as saying [lifted straight from the article]:

"We had an initial vote back in 2007 of nearly 50 people and the vast majority were in favor," Jachwitz said. He did acknowledge that 21 members of the group last week submitted a letter asking for Norway to oppose Ooxml. "Our vote reflected the majority opinion," Jachwitz said. "I do not see that it was improper."

And Roger Frost of ISO in Geneva said in the article,

We have received background information from them and have no reason to question the validity of their vote.

Additionally, coverage in the Norwegian press (Aftenposten) has a quote from the Ministry of Trade and Industry. Here is the unofficial translation of the quote from the paper:

The Ministry has nothing to criticize Standard Norway’s handling of the Norwegian voting procedure regarding the Microsoft-standard Open XML and the ISO-approval. – The Ministry does not engage in standards processes. It is the responsibility of Standard Norway to execute standard processes in a proper manner. We have now received a brief from Standard Norway on how they handled the process, says State Secretary Anne-Lene Svingen (labor party).

(My analysis) I have a colleague in Europe who is tracking this closely as well - Stephen McGibbon's post. The situation in Norway has emerged as one of the more contentious around the world. When I look at the situation there are a few key factors that jump out at me:

First, Standard Norway, at the beginning of the process, was clear in that the decision process would not happen based on a majority vote in the committee. In spite of this fact, the anti-Open XML participants inflated the committee with their representatives just prior to the Sept. 2 vote seeking to influence the decision based on a majority vote - Standard Norway immediately rejected that proposal. The curious part is that as long as the decision went their way (for the anti-Open XML community), they made no complaint. Following the Sept. 2 vote of “No with comments,” there was no process concern from the anti-Open XML community even though the process was identical to what has happened following the BRM process.

Second, after all of the “committee stuffing” claims from IBM, it seems that both IBM and Google joined the committee just two weeks before the final March 28^th meeting. Ironic, no?

Finally, Standard Norway repeatedly stated following Sept 2^nd that the key issue in deciding the final Norwegian vote is to what extent the 12 Norwegian comments were sufficiently met. The fact that the comments were addressed then drove a decision to move to yes.

***Update***

There is a call for a protest march on the Oslo SC34 meeting. I'm not sure of this, but I'm guessing that this is the first time an SC34 meeting has been protested.

Country: Croatia

Criticisms: Groklaw

Response:

Croatia was one of the countries that voted yes for DIS 29500 on the September 2nd ballot. A month after the ballot resolution meeting, Croatia maintained the yes vote, reflecting the understanding and approach of the members of technical committee. There was an effort by Open XML opponents to change this outcome. During that effort, several policies and procedures were violated when the Open XML opponents sought to organize an electronic ballot at the end of the voting period without the consensus of all TC members. Very late in the process a large number of additional members were added to the committee to vote no (without having been part of the process up to that point). The attempt to overturn the vote and not following the policies and procedures defined by NB’s rules was declared invalid by the National Body and is currently under investigation.

IS29500 - Open XML Is An International Standard

jasonmatusow — Tue, 01 Apr 2008 15:52:00 GMT

ISO has distributed the results of the Open XML vote to national bodies (**UPDATED) resulting in leaked information - but now confirmed by ISO in a press release. DIS 29500 has become IS 29500. In regular person speak – Open XML was adopted as an international standard by ISO/IEC JTC 1.

This standard has received more technical and political attention than any specification in the history of the ICT industry. Genuine industry competition around office productivity applications fed a heated exchange of technical considerations and philosophical positions regarding standardization, intellectual property, and most certainly document format technology. In the end, all of this – from the most ardent critics to the dedicated supporters of the specification – contributed to the improvement of the Open XML specification which ultimately led to its adoption as an ISO standard.

DIS 29500 failed to pass the Sept. 2 ballot by missing the super majority requirements. The fact that the ballot resolution process – conducted intensively over a seven-month period - produced such strong technical work and quality engineering engagement resulted in many of the “no” votes changing to “yes” as contemplated by the JTC 1 Directives. This happened because these national bodies considered the substantive changes to the specification and felt that their concerns had been sufficiently addressed -- leading to the position that the specification should be adopted as an International Standard.

The spec is genuinely better today than when it started. The Ecma 376 version is already broadly implemented across multiple platforms. Now the work continues in SC34 on maintenance and with product teams throughout the industry as they make use of the new standard.

*******

Given the focus on this topic throughout the industry, I’m going to take the time to put down some extended thoughts about the standard and where we are today. (Caution – long post) I think it is worth discussion some of the macro factors that surround Open XML.

1. It is imperative that you own your data – and control its future. Within this context, XML-based document formats are good for society at large. The promise of the W3C specification that gave us XML in the 1990’s is now being realized in a myriad of ways -- through new protocols, new document formats, and new capabilities of applications. The innovation made possible by this technology – XML – is changing the very face of the industry (of course coupled with the advancement of processing capacity, and core infrastructure such as the continued spread of network ubiquity etc.) and the extent to which users are gaining greater control of their data.

2. Those who create applications need to invest in building the bridges that enable the effective exchange of data. This is a significant statement, and one that I could write a many thousand word essay on to explain. Suffice it to say that this is a critical aspect of what Microsoft has been and will be doing on interoperability. Every vendor needs to think across the full spectrum of the products they build, the work they do with the broader community, the access they give to their IPR, and the work they do with standards to achieve this goal.

3. Hundreds of organizations were involved in the JTC 1 process. Like most software standards, Open XML was a contributed specification. While the original smaller specification came from a single organization (Microsoft in this case), the specification was improved through the input of more than 20 organizations in Ecma TC 45 originally (including key users and competitors), and then from hundreds of parties through the JTC 1 process. I am greatly encouraged by the participation by all parties (for and against) as the process resulted in a better specification. As I stated before, significant industry competition factors around applications created a highly contentious environment, but out of that came an improved specification that is meticulously documented and gives independent implementers what they need to be successful.

4. Governments requested that Open XML be standardized. More than 2 years ago governments requested that Microsoft standardize the default format of Microsoft Office. Since the late 1990s Microsoft had been working to move away from binary formats to an XML format. That engineering effort culminated with the move to Open XML as the default format for Office 2007 and the contribution of that specification to Ecma. That has all resulted by responding to this request from governments.

5. Open XML is creating new opportunities throughout the industry. Open XML has opened the door for partners of Microsoft, customers, and competitors alike to create innovative solutions and to tap into the marketplace opportunity of Microsoft Office customers. We are already seeing applications in the healthcare, mortgage lending, manufacturing, eGovernment, insurance, document management, mobile devices, and many more segments that are taking advantage of Open XML. While some of these implementations are in association with Microsoft Office, many more are completely independent of it. I hope to see an explosion of innovation surrounding this format as it will benefit all parties.

6. The future of the specification is in ISO/IEC’s hands. A contributed specification is just that – it is “contributed.” Microsoft is like everyone else in regards to the future direction of IS29500. Long-term maintenance of the specification will be under the direction of JTC 1 (via SC34) and in partnership (of some form – to be determined if I’m not mistaken) with Ecma TC 45. Microsoft has committed to implementing IS 29500 in its next version of MS Office, and we will document that implementation in accordance with the interoperability principles we announced earlier this year.

I could go on and on, but I want to shift focus to the question of lessons learned. Anyone who has worked on this standard will likely reflect on their experiences. The long-term effects of this effort will be felt throughout the international standardization community as well.

1. International standards are about the long-term, not the short-term. The ratification of Open XML is just the first step in a longer discussion about document formats at the international standards level. ODF 1.2 and 1.3 (currently only under review at OASIS) will come before JTC 1, as will other activities: Open XML maintenance; PDF 1.7 maintenance; China may decide to move UOF to JTC 1; the work that is happening in DIN (the German national standards body) on translation and harmonization. It is a testament to the importance of document formats that so much engineering capacity and business investment is focused on these issues.

2. Politics matter. It became apparent to me early on in the cycle of DIS 29500 that the technical merits of the specification were only partially influential in the discussions of Open XML. The detractors and supporters alike (myself included) took the debate to the court of public opinion and into the political arena. The long discussions held over ODF procurement mandates being placed into statutes, the attempt to exclude Open XML from state-level procurement through policy mandate, and the debates over economic opportunity and industry competition were significant discussions. Each of these exposed different aspects of the debate. And each, to some extent, touched on foundational issues regarding the role of ICT in society. “Lobbying” was thrown about in an accusatory manner by both sides, but the pejorative hides what are some truly critical issues. Frankly, I welcome the fact that OSS advocates, private industry, NGOs, academics, and even other government agencies reached out to each other to discuss these issues. The invective that often accompanied some of these activities was unfortunate – but the end result was an overall, relatively deep discussion.

3. Speed of standards development remains an open-ended debate. One of the most basic criticisms of Open XML was that it should not have been put through the “Fast Track” process. The fact is, Fast Track is a more rigorous process than PAS (by the fact that it has the contradiction phase tacked on to the front of the process) and both move straight to the JTC 1 plenary vote rather than the SC-level work. As governments continue to drive toward eGOV frameworks where they have a favoring of standards that carry the ISO imprimatur (I’m not necessarily saying this is good or bad), then the old issue of speed of development will come to the fore. The software industry has relied heavily on industry consortia over the years due to the desire to get specs into circulation faster than through the slower, and more formalized, international standardization process. Open XML has shown a very bright spotlight on this issue which should merit the healthy, and rational, discussion of how this issue is to be dealt with over time. PDF 1.7 just went through the Fast Track process (with nary a peep from the vast majority of people about it), and ODF 1.0 went through the PAS process. (These are just doc format examples – anyone with a DVD player is using ISO Fast Track standards without famine or draught being caused.) My personal opinion is that nimble performance is going to be a real test for ISO in the future.

Quite frankly there is much more, but this is enough to think about for one day. I’m really proud of the work done by so many organizations in reaching this goal. The FUD-throwers will paint a picture of Microsoft taking unilateral action and thus this result. Anyone saying that is either purposely obfuscating the truth or spectacularly ignorant. The deep technical work done by engineers from around the world representing a truly staggering number of interests is what brought us to this point. Congratulations to everyone involved in helping Open XML become an ISO/IEC International Standard.

Open Protocol Specifications Forum Group	Participate in the top-level forum group.	link
Using the Open Protocol specifications	Ask questions about the Open Protocol documents, their organization, language conventions and references.	link
Windows protocols	Discuss technical content and implementation of the Windows protocols described in the Open Protocol specifications.	link
File services	Discuss technical content and implementation of Server Message Block protocols described in the Open Protocol specifications.	link
Using the Office Open Protocol specifications	Discuss technical content and implementation of the Office protocols described in the Open Protocol specifications.	link
Using the Exchange Server protocols	Discuss technical content and implementation of the Exchange and Outlook protocols described in the Open Protocol specifications.	link
Using the SharePoint Products and Technologies protocols	Discuss technical content and implementation of the SharePoint Products and Technologies protocols described in the Open Protocol specifications.	link

Matusow's Blog

Hello World…Again

A Macro Question About Microsoft And Standards - Oh Yeah - And Is Microsoft Really Committed to Open XML?

Strategic Use of Collaborative Development in South Africa - Follow Up

Open XML, ODF, PDF, and XPS in Office

The Politics of OSS Still Overshadow The Benefits of Collaborative Development

Participation in standards...

IP, RAND, Standards, OSP, ISP - the conversation continues...

More Open XML Discussion - more misunderstandings about standards and IP

Open XML - SC34 Maintenance Agreement

Texas Legislature - Electronic Documents Hearing

More Protocol Documentation - Interop Principles Commitment

Open XML - Where The Rubber Meets The Road

van den Beld Post & Participation - Open XML continued

The Process Challenge - A Predictable Path

IS29500 - Open XML Is An International Standard