Brent Phillips - Interoperability Blog : Open Specification Promise

Interoperability, Choice, and Open XML

brentphillips — Wed, 14 Feb 2007 18:33:00 GMT

This morning Microsoft released a letter outlining its position and intent to foster interoperability with the Open XML file format (a recently passed ECMA international standard) and also raised concerns about competitor activity to interfere with our current ISO standardization process. The letter, IMHO, is long overdue and I’m glad to see it published. Anyway, I’ve thought about interoperability for some time – especially from the customer and market perspective – and have tried to figure out what, if anything, we are doing wrong or half-heartedly with respect to the Open XML file formats. After all, there have been concerns raised about our motive, the size of the specification, and the ‘openness’ of the process for its development and standardization. The letter addresses these issues pretty clearly – nothing we haven’t said before – and I find it difficult to believe that even our most ardent competitors would think this is anything but goodness. Looking at this from a logical perspective our position is pretty self explanatory in fact:

1. We focus on Customer and Industry driven interoperability: The market is the community that matters
We realize that heterogeneity happens. In response, Microsoft is fostering a pragmatic approach to achieving interoperability ‘by design’ that respects diverse technologies and business models, encourages vendor autonomy to innovate and protect IP, while meeting customer needs of managing the complexity of heterogeneous infrastructure. Examples? Sure…

a. The Interoperability Executive Customer Council has driven significant work stream activity since its first meeting in October

b. The Interoperability Vendor Alliance is evolving with Red Hat being among the most recent to join

c. Novell and Microsoft recently announced their technical roadmap

d. The Open Specification Promise has been made available to release IP for industry use

2. ECMA Standardization.
We worked through ECMA for nearly a year with key industry stakeholders - keep in mind, ECMA’s process is an open one. During its time in the technical committee, the spec grew from 2000 pages to 6000 pages. All but one company voted to approve the specification during its review for standardization – IBM. Looking at Bob Sutor’s blog (he’s the VP of Open Strategy at IBM), he states the following:

IBM voted NO today in ECMA on approval for Microsoft’s Open XML spec.

I think Rob Weir and I (as well as many others) have made it clear in the last few months why we think the (1) Open Document Format ISO standard is vastly superior to the Open XML spec. (2) ODF is what the world needs today to drive competition, innovation, and lower costs for customers. It is an example of a real open standard versus a (3) vendor-dictated spec that documents proprietary products via XML.(4) ODF is about the future, Open XML is about the past. We voted for the future.

Anyway, just wanted you to know.

Couple of points to consider re: those comments…

(1) ODF is incomplete, even for its own intended goals, and is currently being revised through OASIS (accessibility was a key issue in fact).

(2) ODF may be what Open Office needs today – don’t know that the world is screaming for it. If you happen to use Open Office, you may still run into the occasional Microsoft Office Open file formats –which happen to be supported by translators.

(3) What better place to start than the source of the binary files (Not sure I get how XML is proprietary?) We offered an open spec to the industry which grew into what is today. The great thing is that…

(4) While ODF is a forward thinking spec (which is fine), Open XML is backward compatible and future proofed, linking billions (yes with a ‘b’) of legacy binary files with a new world of XML based and extensible documents.

3. The size of the specification.
The spec was not intentionally written to be overly complex or involved. Granted, its long. Very long. 6000 pages. But I think it’s fair to say that we had to document all of the features plain and simple – regardless of how significant or mundane they were perceived to be. As I mentioned before, its size evolved over time as we took input from technical committee participants. The size of the specification reflects the degree of sophistication for the document authoring technology - MS Office is very robust.

4. Access and availability to Implement – No Strings Attached!
As aforementioned, Microsoft introduced an Open Specification Promise under which the Open XML specification was released. Anyone is free to implement all or a portion of the specification to fit their needs and Novell, Corel, and others, in fact, have already announced that this is part of their roadmap. The first round of implementation, of course, may take significant work – it took significant work for Microsoft. And after all, this is a major change in our own technologies to foster interoperability. Once done, however, and as the spec evolves, future iterations will be much more streamlined to implement.

I could go on, but I think I’ve made my point. I encourage folks to read the letter and think about what we’re doing. This is a huge step for the industry and a huge step for Microsoft. Anyone sitting in opposition to this effort must be putting their own interests before those of the market. C’mon IBM – where’s our Attaboy???

Need details on the Open Spec Promise? Check out Channel 9...

brentphillips — Mon, 20 Nov 2006 21:53:00 GMT

If you have 30 minutes and are keenly interested in how Microsoft's new Open Specification Promise works, check out this video at Channel 9. Included in the clip are Jean Paoli, General Manager of Interoperability & XML Architecture; Tom Robertson, General Manager of IP and Corportate Standards Strategy; and Amy Marasco, General Manager of Standards Strategy. I worked on parts of the project for Amy and Tom, and work closely with all three on other efforts. Check it out here...

Microsoft's Sender ID goes OSP

brentphillips — Mon, 23 Oct 2006 20:07:00 GMT

My guess is that most people don't even realize how 'at risk' they are to online threats these days. And what better way to take advantage of someone than by going through a trusted channel – their inbox. In response to these threats, Microsoft released SenderID nearly two years ago to foster online safety by preventing phishing, malware, spam attacks and other e-mail fraud. Today, and furthering its commitment to interoperability, Microsoft announced that it is releasing the SenderID framework specification to the global IT community under the Open Specification Promise. According to the press release, “The application of the OSP will promote further industry interoperability by making the e-mail authentication framework more clearly available to the entire Internet ecosystem, including customers, partners, Internet service providers, registrars and the developer community, no matter what model they use — commercial, open source or academic.”

In my mind - as important as email is to all of us - SenderID is one of those 'under the hood' technologies that we just can't live without. As an industry we fight online fraud every day and it’s only going to get more difficult as phishers (et al) become more sophisticated. Making SenderID available to the community (under any license) will help synchronize the industry to combat fraud with a widely adopted (600 million + users) and highly useful technology. Under the OSP, we are ensuring that anyone who wants to implement the technology – Microsoft’s Intellectual Property - can do so at no risk and completely free of charge. For more detail about the technology and the OSP, read Matusow's blog...

Other resources:
Press pass article here: http://www.microsoft.com/presspass/press/2006/oct06/10-23OSPSenderIDPR.mspx
Interoperability at Microsoft: http://www.microsoft.com/interop

Is it really open vs. proprietary?

brentphillips — Thu, 19 Oct 2006 20:41:00 GMT

...Or how well it works together. Its really about how well we connect people, data, and diverse systems to make processes more efficient right? It should not matter what the pieces are. Leave the choice of configuration to those who best know what they need. We'll meet them where they are!

I am borrowing the title from an interesting article by Simon Moores over at silicon.com entitled "Open Source: The New Front," an opinion piece suggesting that the future of technology is all about interoperability. I could not agree more - especially as he frames it so well in the following statement - so I thought I would share and offer two additional cents.

"By interoperability, I simply mean the ability of different IT networks, applications or components to exchange and use information, i.e. to 'talk' to each other.This goal can be achieved by four means - through the development of software that is 'interoperable by design' (e.g., inclusion of XML technology in software to facilitate the easy exchange of data across different applications); through licensing and cross-licensing proprietary technologies and essential intellectual property; through collaboration with partners, competitors and customers; and through the implementation of industry standards (including open standards and broadly accessible proprietary standards) in products and services."

For my part, I also want to offer that proprietary and open development (suggesting royalty free licensing and community contribution) can, in fact, go hand in hand - or coexist to put it more accurately. Consider Microsoft's Open Specification Promise under which we have released a number of web service specifications and most recently the Virtual Hard Disk Image Specification to the community - royalty free - in order to foster interoperability in the market. Likewise, we are seeing tremendous success of open source projects for the Window's platform - consider MeiRou, Phalanger,GibberMonkey and other projects on CodePlex or the ODF Translator over at SourceForge. Also consider the great work that was done between Microsoft and JBoss or SugarCRM for various interoperability initiatives and the Open Source lab team at Port 25. This is coexistence in action and it gets stronger and more collaborative as projects evolve. Do we compete? Of course, but our collective focus is customer need.

To finish my thought, the biggest mis-statement I hear about software these days is that 'open' (standards, source, etc) is the best way to achieve interoperability. Open development models and open licensing are great things if they work for your business - say if you sell services. But don't raise 'open' as a requirement for interop because open solutions can also be incompatible (as can competing implementations of standards). When this happens, as with non-open solutions, we must remember the unique quality of software as a bridging medium. This is unique to the virtual world of course - it would not be as easy to attach a firehose to a kitchen sink (enough duct tape perhaps), but digitally we get it figured out. I offer Biztalk Server as one example - with over 300 adapters - capable of connecting into any number of non-Microsoft technologies - in essence translating between independent systems.

I don't want to over simplify interoperability by any means, but in lock-step with innovation it happens every single day.

Its how the industry evolves.

Openness @ Microsoft…

brentphillips — Tue, 12 Sep 2006 21:42:00 GMT

Furthering our commitment to working broadly with the IT community to drive interoperability, Microsoft announced an Open Specification Promise this morning to make a number of web service specs freely available to the development community. Follow the link above to see the text. If you want to know how easy it is, here is a quote from the FAQ on ‘how it works:’

'No one needs to sign anything or even reference anything. Anyone is free to implement the specification(s), as they wish and do not need to make any mention of or reference to Microsoft…'Pretty straightforward!

...And the specs themselves?

WS-Addressing, WS-RM Policy, WS-AtomicTransaction, Remote Shell Web Services Protocol, WS-BusinessActivity, WS-SecureConversation, WS-Coordination, WS-Security: Kerberos Binding, WS-Discovery, WS-Security: SOAP Message Security, WSDL, WSDL 1.1 Binding Extension for SOAP 1.2, WS-Security: UsernameToken Profile, WS-Enumeration, WS-SecurityPolicy, WS-Security: X.509 Certificate Token Profile, SOAP, WS-Eventing, WS-Federation, SOAP 1.1 Binding for MTOM 1.0, WS-Federation Active Requestor Profile, SOAP MTOM / XOP, WS-Federation Passive Requestor Profile, SOAP-over-UDP, WS-Management, WS-Transfer, WS-Management Catalog, WS-Trust ,WS-MetadataExchange, WS-I Basic Profile, WS-Policy, Web Single Sign-On Interoperability Profile, WS-PolicyAttachment, Web Single Sign-On Metadata Exchange Protocol, WS-ReliableMessaging

If you are interested in industry adoption of the specifications, see Jorgen Thelin’s blog…

Looking forward to seeing how this evolves in the coming months!