Who Needs Standards Bodies

By eweek  |  Posted 2003-10-26 Print this article Print

?"> I have to ask you this because you said earlier Microsoft has "respect for standards." Whats your stance on working with standards bodies? Do you see it as a necessary evil or something that you feel compelled to do? Well, its certainly not a necessary evil. If you look at what W3C has contributed to the world by creating this asset that we call the Web, that clearly is not a necessary evil. That clearly is a great gift to humankind. So its clearly not that. So what is it?
Standards bodies have an incredibly important role to play in terms of getting vendors to cooperate, in terms of representing user concerns. Its just that theyre not the only role to play. And I think there are times when its important to make sure that vendors really interoperate. And having a published standard is a fantastic first step toward that, but sometimes there needs to be other forums, like WS-I that really does sample code or literally has a budget to put 10 machines in a room—one IBM, one Oracle, one Microsoft, one BEA … and then test those things and make sure that they really work together.
I dont know how to say it any clearer than that. There are lots of components to make sure that vendors really work together because really, standards are about helping with interoperability and making sure things can connect to other things and we can transfer documents from one format to another. And standards bodies have a super-important role to play in that. But weve had plenty of standards that havent achieved critical mass. Weve had X.400, we had X.500, and we had OSI, so clearly its not just having a standards body that brings things to critical mass or creates interoperability. There are other forces that come into play. So Ill say standards bodies are super-important and can be complemented by other processes to really get what customers want. I think that its important to make sure that the customer has an important voice in what were doing as well, and that really thinking about how to balance between a vendors technical objective and a customers business objective is something that we can do a little bit better as an industry. Well, the other question is why do you, rather than work within a standards body on stuff thats already in a roadmap, come up with standards or specs that compete with stuff thats already there? I think what were trying to do is balance pragmatic time-to-market needs with de facto standards needs. And the fact of the matter is it can be difficult sometimes to work within a standards bodys framework. They have specific rules around IP or trade secrets or just specific procedural rules on how often they can meet or how many people need to meet before they can vote on something or before they can modify a spec. And specific rules on who can even see things—whether youre a member or a contributor or part of the working group or not part of the working group. And there are times when youre really trying to drive the industry forward that commercial realities have an important role to play. And weve tried really hard to balance moving Web services forward, really keeping vendors together by doing things like interoperating with IBM, delivering products on their schedule and our schedule and a standards-body track. I think overall weve done quite a reasonable job. I mean, Web services work. They work cross-vendor. And we got SOAP done, we got XML done, we got UDDI done, were working on getting WS-Security done. And so the fact that things are drafted or put out for public review—weve typically done a spec and shared it for comments by posting it on MSDN and revised it based on feedback—then given it to a standards body. And people who have worked in a standards committee understand a little bit about design by committee versus design by other imperatives. And again its just a balancing act. And people can criticize one part of the balancing act saying,"There are too many standards," and people can criticize the other part of the balancing act saying, "I want my product yesterday." And we try to walk that line as best we can. What is Indigo? Its just a codename for our next-generation Web services runtime. Were always implementing Web services technology. We have some in the base product today. Visual Studio .Net 2003 ships with WSE and well continue to enhance those toolkits. The next significant rewrite for our Web services processing pipeline is in Indigo. And when can we expect to see that? I think well see it in the Longhorn timeframe.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel