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.