Open XML Translator

As usual, I'm slow in my blog posting - but I've been a bit busy on the back end working with a great team of people to get the Open XML Translator out the door. (You can read more about it here)

Some good posts on this from others: from the Office team - Brian Jones did a solid posting, Stephen McGibbon from MS showed the tool, Jerry Fishenden from MS also weighed in. If you want an independent, and very smart, take on the news - go check out what Stephen O'Grady at Redmonk had to say. It is long, but looks at the announcement from many angles.

I'm not going to rehash the news here, I'd rather share with you what I think is important about the announcement, and one point in particular that has not been discussed much (Stephen missed it as well) but is critical to the discussion.

1) The Babble Fish:

The Open XML Translator is a two-way translator. If you put Open XML in, it spits out ODF. If you put in ODF it spits out Open XML. This means that the translator project itself is independent of the applications that will produce and consume the document formats. 

We have been saying throughout the work at Ecma on Open XML that we expect to see a myriad of implementations of Open XML - probably not too many full implementations (heavy lifting on development), rather many partical implementations. (Think of a vertical application developer such as an insurance package who implements part of Open XML in their solution.) This means that there may be software out there that has only a small piece of Open XML in it, but those pieces will be conformant to the spec. The translator will be just as useful for them as for something like Office which is dealing with a full implementation.

2) Green Fields Gold Rush

The world of XML document formats is going to create something of a gold rush for smaller ISVs who are able to offer value-add to the converter space. The heavy lifting on the conversion will be handled by community projects. For you long-tail enthusiasts out there - the translators themselves are the short-end of the tail. Single solution for a market of millions. But, this is where the big costs are. For the small ISV - this is the place to be a contributor to the projects and to build a rep in the space. The middle part of the tail is where add-on projects are that the ISVs can lead and show value. These can either be collaborative projects or closely-held in order to drive economic opportunity for them. Then, there is the long-end of the tail. All of this work should enable the customization and capability for the users of theses translation tools (consulting opportunity for the ISVs and SIs). Out at the long-end of tail, your development cost:potential revenue ratio tends to stink - so it is all about enablement. 

That is a long way of saying that there is opportunity in them-thar-hills.

3) Licensed to Use

We were very careful in our choice of licenses for the translator project. This project is designed to enable both community and commercial use of the code base. We want people to participate, but like any OSS project there is a maintainer, contributors, and community members making suggestions and submitting bugs etc. The license itself though means that the commercial community who simply may want to consume the technology and then modify themselves (without sharing back) is possible as well.

So to tie things together - the translator is not coupled with any one application, the XML-based document market is going to grow exponentially over the coming years, and the translator will be professionally developed while being open to the community.

All good from my perspective.

Comments

• Anonymous
  July 06, 2006
  Jason,
  
  I'm confused.  In an article (http://www.eweek.com/article2/0,1895,1985410,00.asp) it claims that you said that MS is not contributing code nor architectural guidance to the project.  So, what exactly is Microsoft contributing to this project?
  
  It appears from the one article you linked to that Microsoft is funding other companies work on the project (i.e. ya'll are outsourcing the work).  Is that the full extent of Microsoft's contribution?  (Not trying to minimize it, just understand it)
• Anonymous
  July 06, 2006
  Swashbuckler - If you read the original story you'll see that Vaughn-Nicols got it wrong
  
  http://www.eweek.com/article2/0,1895,1985186,00.asp
  
  We ARE providing architectural guidance and funding to the 3 companies involved. We are not currently contributing code.
  
  Does that help?
  
  Jason
• Anonymous
  July 06, 2006
  Yes, that helps.
  
  A couple of additional questions if you don't mind.
  
  1. A philosophical question: why the BSD license?  Why not a reciprocal license?  Basically, I think of using a non-reciprocal license such as BSD when I want the user to be able to productize what they create.  I think of using a reciprocal license when I'd prefer they didn't.  Since I don't see any reason to productize the converter (to sell it) I don't see why a BSD license would be used.
  
  2. I think I know the answer to this question, but I'll ask it anyway: Why did you decide to put the code on SourceForge instead of CodePlex?
• Anonymous
  July 06, 2006
  Breaking with my long-standing tradition of bringing you the news long after it's broken, I've got some early commentary on the news that Microsoft has announced support for the Open Document Format. This analysis was made possible by the folks...
• Anonymous
  July 06, 2006
  The comment has been removed
• Anonymous
  July 07, 2006
  The comment has been removed
• Anonymous
  July 07, 2006
  So far I've downloaded the pre-alpha "OpenOfficePlugin" - last year - and the alpha "OdfConverter".
  
  Only this year did I have the software guaranteed to do something with them - Visual [programming language] Express.  Or at least I assume that I can throw OdfConverter at Visual C# Express and won't face a barrage of errors, cause I haven't got around to it yet.  I haven't tried it on Mono yet, or dotGNU.
  
  The code looks clean, and I like the BSD license.  What I'm interested in - because I encounter a lot of people still using these products - is getting it to work on MS Office 9x.  I do have legitimate copies of both MS Office 97 and MS Office 95 and it seems a shame not to make use of OdfConverter and MS Office 9x to allow some of the poorer computer owners I meet, to access government documents if New Zealand follows the current trend.  I mean, MS Office 9x does write to html, so I don't see lack of XML-support as a show-stopping problem.
  
  What I need is a full and complete MSDN core-dump of how MS Office 9x supports plugins and file formats.
  
  The only problem I'm seeing at the moment is that it's only ODF2OXML at the moment.  I would've thought it was going to be bi-directional even in alpha and only wordprocessing.  That's a bit slack.  I expected better.
• Anonymous
  March 28, 2008
  I have repeatedly made the argument that it is bad logic that leads you to the conclusion that there