IM Expectations

by Peter Saint-Andre

2004-12-02

We've been having quite the conversation in the last few days about what features "Jabber" does and does not offer. It seems that some folks have a few misconceptions about what "Jabber" is and does, based in part on varying expectations. So here's my attempt at clarifying things, mostly in reply to Ted Leung's latest post.

First, there is no such thing as "Jabber" -- it's an adjective, not a noun. If "Jabber" refers to anything, it refers to a set of streaming XML technologies, along with assorted implementations and deployments. Since Jeremie Miller invented "Jabber" back in 1998/1999 and began building it out with a small team of developers, here's what we (i.e., the Jabber developer community) have built (and please understand that all of this is pretty much a work-in-progress):

In the early days, the wire protocols used in the Jabber community were something of an afterthought, and the innovation was pushed by the core jabberd server team, with clients like Winjab and Gabber often playing catch-up. Over time we tried to put more structure around protocol development (enter the Jabber Software Foundation), which is why today software development often lags behind protocol development (whether that's good or bad is open to interpretation). So not all the features defined in various protocol extensions have made their way into all the clients, and some of the protocols are not yet implemented in any clients or servers, but over time self-respecting developers do usually add those features (but know that many coders just want to write a basic IM client and never implement the advanced stuff because the initial fun or challenge has worn off).

While this relatively small, anarchic, and cash-strapped Jabber community has been working away since 1999, four multi-billion dollar corporations -- AOL, Microsoft, Yahoo, and (in the enterprise space) IBM -- have poured lots and lots of resources into their own proprietary systems. I don't want to make excuses for what the Jabber community has or has not accomplished, but please do not underestimate the significance of the IM landspace and its impact on what is realistic to expect from the Jabber community. I welcome you to imagine for a moment a different email landspace, in which SMTP was not developed and accepted as quickly as it was. Imagine that, today, AOL, Compuserve, and Prodigy had hundreds of millions of users but still did not interoperate; that you needed to have three or four email accounts and run multiple clients to talk with people on all the different services (and one for your company email system, too); that each service attempted to compete on a wide array of features, but implemented those features in different ways; and that there was this cool little "SMTP" community run by some geeks out there somewhere, but "no one uses it" and "SMTP is dead" because it doesn't have the mind share, market share, or marketing dollars to compete with the big boys (we'll even throw in X.400 so people can complain about how the IETF hasn't settled on a single standard!). Sure, SMTP is an open standard but SMTP Client X doesn't yet do all the cool things I can do in my Compuserve client, and did you see that Prodigy announced weblog integration yesterday? Sure, I can run my own SMTP server so that I don't have to send all my communications through someone else's network, but that's a feature for geeks and besides the last SMTP server I downloaded didn't support all the latest SMTP extensions so SMTP sucks.

Welcome to our world.

No, "Jabber" does not yet do it all, on all platforms, with the convenience of being able to download one single Jabber client for your OS of choice that implements every imaginable feature (and some we haven't even thought of yet). The Jabber community is essentially defining protocols (think the W3C of the IM or streaming XML world), coding servers (think Apache) and clients (think Mozilla) and libraries (think Python, CPAN, Java, etc.), building out an interconnected network, and addressing everyone's security and privacy concerns, all at the same time -- and facing down AOL, Microsoft, Yahoo, and IBM, to boot.

No, it's not always clear what cool features "Jabber" offers. You go to www.jabber.org and you get a list of protocol specifications. That's because the Jabber Software Foundation is focused on protocol development -- when you go to www.ietf.org all you get is a list of RFCs, does that mean the Internet sucks? Certainly the jabber.org website could be better or more user-focused (in fact two separate efforts are underway to create more end-user-focused websites), but the JSF's core customer is the developer community, and the JSF depends on the coders of the world to build software based on our protocols, and on service providers to deploy kick-ass services.

No, "Jabber" is not perfect -- we need better clients, better servers, better libraries, better documentation, better websites, better deployed services, and much else besides. The way to improve it is to help. Submit bug reports, feature requests, and code patches, or collaborate with developers directly to get your desired features added. Help with documentation (e.g., write online help for your favorite Jabber client) or translate a client interface into another language. Convince your company to adopt the technology (lots of companies already have, from blue-chip investment banks to Brazilian travel agencies and everything in between). Run your own server rather than using jabber.org or one of the other big services (which are all administered by volunteers). Help with one of the nascent end-user website efforts. Encourage other open-source projects to work on Jabber-related software (e.g., one could probably port jabberd 1.4.3 to the Apache Portable Runtime, and it'd be cool to see a Mozilla-based Jabber client a la Firefox and Thunderbird).

"Jabber" started with one person in 1998 and perhaps a dozen core developers in 1999, and has grown since then beyond what any of the early contributors expected. The IETF has approved our core protocol. Major, major corporations and governments are deploying XMPP-based services. Companies like Apple, HP, Oracle, and Sun are reported to be developing XMPP-based software, and I'm sure that many other companies are doing so quietly. Open-source developers continue to devote spare time to their projects with very little help or encouragement. We're doing the best we can, and we're not going away anytime soon, no matter how much AOL, Microsoft, Yahoo, and IBM spend on their closed systems. But we need help to take things to the next level.

OK, all that was a bit abstract and more of a rant than I had hoped for. Ted has specific questions about what features to expect from Jabber clients, which client to use on OS X, and so on. I can't lie: traditionally OS X client support has been lacking. There's a short list of recommended clients here (and it's reported that iChat will support Jabber in Tiger), but not all of those projects may offer exactly what Ted is looking for, so he may need to request some features or submit some patches (yes, this is open source) -- for instance, lots of Jabber clients don't treat messages of type "headline" as they should be treated (they default to treating them like normal messages), so that may be an opportunity to submit a bug report. As to what features most self-respecting Jabber clients should support, here is my personal wish list:

Does any Jabber client do all of that today? Unfortunately, no. But that's why there are still plenty of opportunities to contribute. So let's get busy!


Peter Saint-Andre > Journal