Today I revisited my .plan for the first time in a month, and was struck by how non-essential some of the entries seem. Distributed calendaring? Multimedia extensions for voice and video? Whiteboarding? Hmm. Are these what Jabber is all about? Right now it seems to me that the answer is no.
Jabber was born on January 4, 1999 when Slashdot featured a story on a new, open-source instant messaging system developed by Jeremie Miller. The early days were highly productive, leading up to the release of jabberd 1.0 in May of 2000. Since then the community has witnessed more code, more contributors, and more process. We formed the JSF in mid-2001 to manage the Jabber protocols in a more open and measured manner, which of course required more process. In 2002 we submitted our core protocols to the IETF -- and, as I can vouch for first-hand, that meant a lot more process and formalization.
No one especially wants to go back to the early days, which were exciting but involved daily changes to the protocols. However, we need to find a balance between process and innovation. The first step, I think, is to back-fill a bit. Sure, voice, video, whiteboarding, and calendaring are all fun applications. But IMHO it's a bit premature for the Jabber community to go off gallivanting in search of cool new applications when we have a plethora of Jabber clients that are at best incomplete and at worst pieces of junk. There is no really good Jabber client for Linux or Mac (though future versions of iChat may address the latter failing). In server-land, the venerable jabberd 1.4 codebase is stable but showing its age, and it's doubtful that it will ever include the XMPP advancements such as SASL authentication, TLS channel encryption, and whitelisting/blacklisting. The jabberd 2.0 codebase contains all those features but is less than stable (perhaps because it's mainly been developed as a heroic solo effort by Rob Norris). We have a powerful publish-subscribe protocol but only one open-source component (thanks to the great ralphm) and no client implementations that I'm aware of. And so on.
All those specs look nice on paper, but they're meaningless without the code to back them up. I see little point in continuing to push forward on more fancy specifications when 90% of the clients out there haven't even implemented pubsub or file transfer yet. So personally I plan to focus only on specs that we really seem to need (a good protocol for "shared groups" is one of them) and to do what I can to contribute to the open codebase, starting with the recently-resuscitated Jabberzilla client, which I hope can be a fully standards-compliant and cross-platform Jabber client.
So you can add a new mantra to my battle cry of "email delenda est": fewer specs, more code!