Feedback continues to pour in regarding my previous posts on the state of the Jabber community. Various good discussion list threads and one-to-one conversations have led me to rethink some of my assumptions about problems and solutions. Since step one is to correctly diagnose the problem, we need to get that right before we can figure out the best course of action. Here is a short list of what I see as deficiencies in the Jabber community:

  1. the main free servers (jabberd 1.4.3 and jabberd2) are protocol-incomplete, hard to code for, and hard to administer
  2. we have way too many incomplete clients, very few semi-complete clients, and no protocol-complete clients
  3. too many Jabber clients have horrible user interfaces
  4. we don't have good, high-level libraries for the main computing platforms
  5. we have too many one-person projects
  6. we don't have good documentation (user guides, admin guides, developer guides, code comments)

It's not clear that creating one reference implementation (or, realistically, one server, one client, and one library) is the way to solve these problems. Yes, we have too many clients, but some of them are close to protocol-compliant and it might be better to encourage developers to make them fully compliant rather than trying to write one cross-platform client (whose user interface would likely be sub-optimal on several platforms). The same goes for servers: it might be better to expend the effort to push jabberd2 over the top rather than to write a new server. One way to encourage this would be for the Jabber Software Foundation to finally develop a protocol compliance testing process (initially based on the protocol suites defined in JEPs 73 and 117). A contributing factor here may be that, although the JSF cares about protocol compliance, most end users and system admins don't. Do people really care if their clients and servers use SASL/TLS for XML streams? Seemingly not.

Naturally, protocol compliance does not address ease of use. The fact that various Jabber clients are not user-friendly, or that various Jabber servers are hard to install and administer, goes beyond protocol compliance. Although JSF members may have opinions regarding usability, the JSF may not be the best body to test for usability. On the server side, the problem is often one of packaging (notoriously hard) and documentation (notoriously boring). On the client side, the problem is that usability is more art than science, and many (most?) developers are not attuned to usability. Here again, I'm no longer convinced that a reference implementation would save the day.

As to libraries, one comment that Peter Millard and Ryan Eatmon heard repeatedly at OSCON 2004 was that it would be nice to have a great Python library. But there already exist several good Python libraries, some of which need to be extended to support more high-level functionality. One of the challenges with regard to libraries is that everyone has their preferred language: some folks want to code in Perl, others in Python, others in Java, C, C++, or whatever. Another challenge is that developing applications for particular platforms simply cries out for platform-specific libraries; for example, Macintosh developers these days most likely want a Cocoa library written in Objective-C, not a Python library. This might be an area in which a company like Apple could make a strong contribution to the Jabber community.

The plethora of one-person projects is a tougher nut to crack. Personally I'm not opposed to one-person projects per se; the problem arises when the project is one that many people depend on and the one developer loses interest. The result is stagnation. One thing that would help is well-documented code, but most coders don't take time to comment their code in depth, and your typical tech writer doesn't grok the code well enough to comment the code or write helpful code-level documentation. I'm not yet sure how to address this, but I'm sure that other open-source projects have run into the same issues, so there must be some best practices in this area. Further research required.

As to documentation, I don't think the existing user guides and admin guides are that bad (perhaps I'm biased, since I wrote many of them). It would be great if the leading Jabber clients included inline help (I've promised Peter Millard that I would do this for Exodus, but I haven't gotten to it yet -- my bad!). Some components contain only skimpy READMEs, which are acceptable for fairly geeky sysadmins but aren't all that friendly (here again, the answer may be packaging -- but who wants to do packaging?).

One of my correspondents pointed out that the impetus for all this may been my recent switch to OS X, for which there is no good Jabber client. That may be so. But I think the issues go beyond my personal frustration with Jabbering on the PowerBook. Feature incompleteness, poor documentation, unfriendly interfaces, and bad packaging are problems endemic to the open-source community, and perhaps even to code in general (though commercial software developers often do a better job on some of these because they can pay people to work on things that aren't all that interesting). I'm not yet sure how we can address these issues in the Jabber community and I'm less convinced than I was that reference implementations are the answer, but I do know that we need to find a way to address them if we are to thrive.

May the conversation continue!

Peter Saint-Andre > Journal