Open Source and Open Standards

The intersection of protocol, source, and community. Peter will be speaking on this topic at the upcoming O'Reilly Open Source Convention.

How critical are open standards to the viability of the open source community? And which is a stronger guarantee of openness in the technology ecosystem: open standards or open code?

In a recent article entitled Open Standards versus Open Source, Jonathan Schwartz of Sun Microsystems argues that open standards (i.e., open protocols) are more important than open source code. While he sets up an opposition between standards and source (that little word "versus" in his title), in reality there is no such thing--the two are mostly orthogonal to each other and, as we shall see, both are necessary.

As you might expect, Schwartz's argument has not gone unchallenged. For example, Kevin Werbach points out that open source projects depend on open protocols (think Apache and HTTP, Mozilla and HTML/CSS/JavaScript, Sendmail and SMTP), but that proprietary products do, too (IIS, IE, Exchange). And Dave Winer, while cautioning against the often-obfuscated output of the major standards bodies, celebrates the diversity that results from open formats and protocols: small development houses are free to create closed implementations and thus are not tied to restrictive licenses such as the GPL.

Yet the landscape is even more nuanced. For instance, closed formats and protocols do not necessarily keep out open (or merely unapproved) implementations. We see this in document editing with AbiWord and OpenOffice, both of which will read and generate Microsoft's closed document formats with a fair degree of accuracy. We see this also in the instant messaging space with clients like Gaim and Fire, both of which enable users to communicate with the open Jabber network as well as the closed services of the legacy IM providers (AIM, ICQ, MSN, and Yahoo). Thus closed formats and protocols are not necessarily the death knell for open source. Unfortunately, they do quite effectively limit implementations to mimicking the original (which is one of the common criticisms of open source). So open formats and protocols do matter.

As with so much else in life, the issue comes down to a question of power. Big companies usually prefer to control formats and protocols. That is why they often dominate official "standards" processes through their overwhelming involvement in ostensibly open organizations such as the IETF and W3C, let alone industry consortia such as MPEG or the Open Mobile Alliance. Too often, official standards processes keep smaller companies out of the loop, as Dave Winer legitimately complains. Winer's approach is to develop open formats (such XML-RPC) outside the auspices of the large standards organizations, then evangelize them independently to both open source and commercial developers.

Dave Winer's success with this approach points to the critical importance of the "third leg of the stool": an open community. An open protocol or format that is dominated by big companies (with only one marginal open source implementation or a few token offerings from smaller developers) is not a healthy ecosystem. To really thrive, a protocol needs a wealth of implementations--some closed, some open, some from big companies, some from smaller development houses, some from open source projects. And those implementations must engender a true community in which the people who do the work and use the software can easily join together to share information and learn from each other (this is what Tim O'Reilly calls the architecture of participation).

So what is a standard? Some people think that when the IETF or W3C approves a protocol or format, it thereby becomes a standard. But standardization is not a matter of approval; rather, it is a matter of acceptance in the market. And what is the market? It's a complex stew of projects and organizations who develop and use the emerging standard. In fact, it looks a lot like the ecosystem of developers and users, but written on a global scale. Not all standards are open (for example, MS Word and PowerPoint). However, when formats and protocols are open, then open implementations that are technically strong usually (but not always) tend to be accepted by the marketplace as standards.

Indeed, often a particular implementation of a certain protocol becomes not only a standard but the dominant market-maker. For example, Apache is the dominant web server and a protocol like HTTPng failed to catch on in large part because it lacked support in the Apache community. We see the same phenomenon in the Jabber world, where the jabberd server is the dominant player. So although diversity is a good thing, it's much better for the health of the ecosystem if the dominant implementation is open rather than closed. A strong open source "anchor" helps ensure the openness of the underlying technology.

In the Jabber community, we have pursued something of a hybrid approach. First we simultaneously created the core protocol and open source implementations, then we grew the developer community and user base (as well as the number and range of companies involved in development and deployment). Once that foundation was strong, we finally sought standardization of the core protocol through the IETF's XMPP Working Group, while maintaining a more nimble Jabber-specific community standards process managed by the open Jabber Software Foundation. Only time will tell if Jabber/XMPP becomes a standard for real-time messaging and presence. But the Jabber community is definitely focused on strengthening all three legs of the stool: protocol, source, and community. And given everything that's happening with Jabber and XMPP these days, we may well be witnessing the emergence of an Internet standard.

Peter Saint-André is executive director of the Jabber Software Foundation and primary author of the XMPP Internet-Drafts.

Return to ONLamp.com.