Standards competition: A good thing?

Competition on many levels
In the final analysis, market forces drive standards efforts -- in other words, customers have the final say as to which standards they will adopt and demand from their suppliers. The best-crafted standard is entirely useless if there's no market demand for products that support that standard. Contrarily, many standards become widely accepted in spite of technical limitations or other problems. Customers buy products and services that meet business needs, and if one particular product that supports a standard is better able to meet those needs than one that isn't, customers will buy it. It's as simple as that.

Of course, vendors understand this basic principle of standards adoption. After all, vendors are for-profit companies, and will only cooperate with their competition if such cooperation will lead to more satisfied customers and increased revenues for themselves. But make no mistake, successful vendors are tough competitors, and thus even cooperative initiatives are fundamentally competitive at some level. This "coopetition" reality pits different motivations and constituencies against each other and pervades the Web services standards process, in several different respects:

• Industry behemoths vs. smaller players -- it is only rational for "800-pound gorillas" like IBM and Microsoft to leverage their position of strength to drive standards efforts. On the other hand, it also makes sense for smaller players to band together to lead their own standards initiatives. For other smaller vendors, riding the coattails of a market leader -- especially if that company is a partner -- makes the most sense.
  
  
• Small, exclusive consortia of vendors vs. large, inclusive consortia containing vendors and IT users -- There's an old joke that a committee is a creature with twenty legs and no brain, and it's true that the more participants a team effort requires, the longer the decisionmaking process will take and the more mediocre the resulting product tends to be. As a result, in some instances it makes sense for small groups of vendors to hammer out the details of a specification before submitting it to a wider standards body -- assuming they ever do so. On the other hand, including the buyers and users of IT products and services in the standards creation process, while more time consuming, is more likely to meet business needs right out of the gate.
  
  
• Royalty-free vs. limited intellectual property rights -- To remain a viable business, every vendor must have some unique competitive barrier that prevents other companies from usurping their customer base. Most vendors reserve some of their intellectual property as proprietary, while providing other technology for the sake of developing their prospective market. The question vendors face is where to draw the line -- err too far on the side of royalty-free contributions, and you leave money on the table, but go too far toward limiting the use of your contributed IP, and risk that customers will adopt a competing technology or none at all. In some instances, smaller vendors up the ante by staking out IP claims that attempt to block the ability of larger vendors to capitalize on emerging market opportunities. In these cases, standards development looks more like a chess match than an attempt to meet customer needs.
  
  
• Conflict between standards bodies -- In the Web services world, there at times seems to be competition between the standardization efforts of the W3C and those of OASIS. While competition between products and even specifications are to be expected, competition between standards groups is problematic. If this were a soccer match, you wouldn't be able to tell the players by their uniforms, because so many participants are on more than one team. In fact, the competition between OASIS and W3C is primarily a difference of organizational goals and standards-creation approaches rather than a case of direct competition between the two organizations. OASIS is well known for the ability of members to easily propose and work on new specs which then work through a relatively rapid winnowing process, while the W3C is more deliberate and methodical about the specifications it creates.

Why Web services are different
We're optimists here at ZapThink, but we're also practical. The pessimistic view that today's standards competition and controversy will lead to fragmentation rather than convergence is a reasonable one. Pessimists point to the Unix story, where a single de facto standard splintered into numerous incompatible vendor implementations. Web services, however, are different from Unix in a fundamental way. Unix vendors sought to protect their hardware market share by retaining control over the independent software vendors who wrote applications for their operating system. ISVs acquiesced to the demands of each Unix vendor when customer demand justified it.

Web services, however, are not operating systems. They're not even products of any kind. Web services are really nothing more than standards-based interfaces to software functionality, intended solely to foster interoperability among heterogeneous systems and applications. While there were perfectly good reasons to develop a proprietary flavor of Unix, the whole point to Web services is to be interoperable. "Fragmented Web services standards" is an oxymoron that makes no business sense. And if there's no money to be made, then companies won't do it.

The Liberty Alliance vs. WS-Federation specifications are a case in point. There is simply no business motivation for having two competing federation standards. After all, federation means interoperability among independent systems. If we had two federation standards, then we'd need some kind of "super-federation" standard that would specify how the federation standards interoperated, and that would obviate the need for those standards altogether. So, one way or another, when the dust settles, there will be one identity federation standard. There's bound to be quite a ruckus in the meantime, but the competition over Web services standards is a game that will have winners.

For more information:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
• Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.