There's a good conversation happening in the blogosphere right now about the interplay of open standards and open source (a topic on which I'm speaking at this year's OSCON). The conversation started with an article by Sun's Jonathan Schwartz and has continued with weblog entries by Kevin Werbach and Dave Winer, among others.
Jonathan Schwartz sets up an opposition between standards and source (that little word "versus" in his title), but in reality there is no such thing -- the two are mostly orthogonal to each other. Kevin Werbach points out that open-source projects depend on open standards (think Apache and HTTP, Mozilla and HTML/CSS/etc., 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 -- developers are free to create closed implementations and are not tied to restrictive licenses such as the GPL.
Yet the landscape is more nuanced. For instance, closed protocols do not necessarily keep out open (or merely unapproved) implementations. We see this in document editing with AbiWord and OpenOffice (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 open-source clients like Gaim and closed-source clients like Trillian (both of which enable the user to communicate with the open Jabber network as well as the closed services of the legacy IM providers: AIM, ICQ, MSN, and Yahoo). So closed protocols are not the death knell for open source, although they do quite effectively limit implementations to mimicking the original (which is one of the traditional criticisms of open-source software).
As with so much else in life, the issue comes down to a question of power. Big companies would prefer to control formats and protocols, which is why they often dominate the official standards process through their overwhelming involvement in ostensibly open standards 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. His approach is to develop open formats and protocols outside the auspices of the large standards organziations, then evangelize them independently to both open-source and commercial developers.
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 a community in which the real people who do the work and use the software can share information and learn from each other.
So what is a standard? Some people think that when the IETF or W3C approves a proposal, it thereby becomes a standard. But that's far from the truth. A format or protocol or technology becomes a standard when the market decides it is. 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, except written on a global scale. Eventually, if a technology is technically strong and enough people adopt it, it will become a standard. Indeed, a particular implementation of a certain technology may become a standard -- for example, Apache is the standard for webservers, and a protocol like HTTPng failed to catch on because it lacked support in the Apache community. We see the same phenonmenon in the Jabber community, 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.
The Jabber community has pursued something of a hybrid approach -- first creating open-source implementations of an emerging protocol, then growing the developer community and user base (as well as the number and range of companies involved in development and deployment), and finally seeking 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 Jabber Software Foundation. Only time will tell if Jabber/XMPP becomes a standard for real-time messaging and presence. Right now we're focused on strengthening all three legs of the stool: protocol, source, and community. But given everything that's going on in the Jabber world, I have a good feeling that we're seeing the emergence of an Internet standard.
The conversation continues...