Standards Competition: A Good Thing?

A few weeks ago, the Liberty Alliance released their business requirements and guidelines for wide scale identity federation. At around the same time, the IBM and Microsoft-led consortium charged with developing the WS-Security roadmap of specifications released the first public version of their WS-Federation specification, which aims to enable federation of identity, attribute, authentication, and authorization information. The press jumped all over this seeming competition between identity federation specifications, issuing headlines like Infighting Unravels Web Services and Rivalry Bogs Down Web Services. ZapThink was the first in line to point out that the world doesn’t need two competing identity federation standards, but do we see Web Services unraveling or bogging down as a result? Hardly!

On the contrary, ZapThink believes that competition on many levels makes the standards process more robust, and the final standards that emerge when the dust settles end up stronger and more useful than standards that result from a process light on competition and controversy. Our belief that such competition is actually a good thing for the industry, however, goes deeper than the simple capitalistic perspective that competition breeds higher quality products. Instead, we believe that the Web Services standards process is fundamentally different from other standards efforts, because Web Services’ raison d’être is interoperability.

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.

So, take all these different levels of competition, stir in a good measure of politics and sprinkle with a good number of strong personalities, and you’ll get what we see today: wrangling, fingerpointing, and a lot of brouhaha. But step back from the fray and you’ll get a different picture — a picture of a healthy process that in the end will meet the needs of customers who are purchasing technology in what is for now an emerging market.

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 Serv
ices standards is a game that will have winners.