The power of standard protocols

I've spent the past few months as the primary developer at a very small company. An important technology to this company is Instant Messaging, as it plays an essential part in our approach to unified messaging.

This has meant that I have had to build, in-house, our own implementation of an XMPP / Jabber IM stack. XMPP Is a standardized protocol for IM communications, the full details of which you can find here. I chose it for a number of reasons. First, XMPP / Jabber is one of the few IM protocols where federation - that is, the ability for custom domains to interoperate with other XMPP / Jabber domains - is the standard order of business. That isn't an essential aspect of XMPP / Jabber, as it is fairly easy to create a closed XMPP network, if you so desired. It was originally developed, however, as a way to escape the "walled garden" approach to Instant Messaging, and those origins have shaped the tendency in the XMPP / Jabber community to be friendly towards messages from other XMPP / Jabber domains.

Second, the XMPP / Jabber community has given a lot of thought to interoperability with the non-XMPP / Jabber networks. That's important, as for all XMPP's benefits, most of the IM world still continues to use proprietary IM protocols.

The third reason is more a hindsight justification I would use if I could go back in time, knowing what I know now, and decide again which IM protocol to use as the basis of our IM work. Implementing a standard specification is really a great way to understand everything a particular protocol can do. That has certainly applied to the work I am doing, and my knowledge of XMPP gleaned from my experience of writing libraries that speak the protocol has helped immeasurably in terms of quickly rolling out new features.

I've also had a chance to come to grips with the details of other IM protocols. Comparatively speaking, XMPP is an elegant and clean protocol. XMPP is built around the exchange of XML "streams," a fact that imposes XML's sense of structure onto endpoints in XMPP communication. Debugging is a lot easier than I've experienced with other protocols, as XML is a fairly self-describing syntax (self-describing to developers, not end-users, a point I've made to people at past companies who thought it a good idea to tell customers to manually edit XML configuration file, rather than ship an existing graphical editor for the file). The beauty of XMPP makes the protocols used by proprietary IM networks seem downright ugly by comparison, but I think XMPP is a cleaner approach to IM communication than even SIP (though SIP does have a number of advantages, is still quite clean, and is certainly dominant in VOIP).

Bottom line, though, I would have a hard time understanding why anyone, at this late a stage, would opt to build their own IM protocol when standardized variants such as XMPP and SIP exist.

I'm clearly someone who is a fan of companies making money. Companies that fail to make money have a hard time pushing technology forward, and any product strategy needs to enable the company to monetize their products effectively. This might motivate some companies to opt to create a proprietary in-house protocol as a clone of existing standard offerings, as that is a sure-fire means by which to ensure that everyone has to use your products.

Though this is a typical analysis, I think it is very short term thinking. Yes, creating your own protocol builds a certain dependency (not a bad thing, as like I said, making money is good), but it is very hard to build a protocol that is of as high a quality as a standardized variant. Standardized protocols are slow to develop and appear relatively late in the lifespan of a typical technology area. That's a necessary aspect of the standarization process, as you need to have sufficient undertanding of a problem domain in order to create a sensible standard, and once you have that information, digesting it into something elegant takes time.

Once a standard protocol exist, however (an important point, as early entrants lack such niceties), I think its crazy for new entrants not to use it. Using an in-house protocol that is less technically proficient limits your scope of maneuverability further down the track. I've seen it repeatedly at past jobs, and it's a frequent recipe for the long-term failure of a project.

If a suitable standard exist, smart companies use it. There are many other areas of innovation to which companies can apply themselves that represent a better use of scarce resources than re-inventing the product of years of engineering analysis aimed at creating a technology perfectly suited to a problem domain.