Yesterday's entry about what's rotten in the Jabber community has elicited quite a bit of feedback so far. Julian Missig says that there's no such thing as a good cross-platform client. Someone poked me via Jabber to say that all my ideas were great except that Python is a horrible language and let's do all this in C++. Several folks volunteered to help with the Python work (which would probably start with a really good Python library). Others continue the theme and point out that unimplemented specs are useless (to be fair, the older core specs are fully implemented and have been since 1999, otherwise no one would be paying attention to Jabber at this point). So at least we have the juices flowing.
As to whether it's possible to build a good cross-platform client, I'm not yet qualified to say. I would say that the Mozilla folks have done it -- the fact that OS Xers use Safari and Mail instead of Firefox and Thunderbird doesn't imply anything about whether these Mozilla apps are objectively good on OS X, only whether they are popular (for that matter, they're not popular on Windows compared to IE and Outlook, either). The good people at OSAF are working towards something similar with Chandler, and are pouring resources into the Mac version of wxWidgets to make this happen. You can complain that Chandler is vaporware and that Mozilla is a fluke, but people are working on this stuff and even if good cross-platform clients are not a reality today, nothing says they are impossible (lord knows that in the Jabber world there are only a very few good single-platform clients out there, so the problem is not limited to the cross-platform arena). At Julian's blog, temas noted that part of the problem may be the plethora of multi-protocol IM clients; I agree in part (multi-protocol clients tend to settle for least-common-denominator functionality), but developer burnout and single-person projects may have more to do with it. All this is of course pure speculation, and we won't find out if it's possible to write a really good, single-purpose (Jabber-only), cross-platform Jabber client unless we try. I still hold out hope for Jabberzilla but it's a bit early to say for sure if that will succeed (though I plan to at least start helping with some docs and code on JZ soon).
As to a cross-platform server written in Python, here again opinions differ and the only way to tell if it's possible is to try. Immediately people were poking me about scalability (will it scale up to 10,000 simultaneous sessions?). But notice that scalability was not on my list of priorities. A really stable server would be good, but I don't see a strong need for a server that scales beyond 1,000 concurrent users. That won't help us on jabber.org (where of the 200,000+ registered users we usually have about 6,000 online at any one time), but most smaller companies, schools, non-profits, and ISPs (80% or 90% of the "market") would do just fine with a server that scales to 1,000 concurrent users. Larger organizations tend to have lots of money and therefore can talk to one of the commercial XMPP server vendors.
The other day, Mitchell Baker posted some thoughts on building open-source communities based on a BOF that happened at OSCON 2004 (Jabberites Peter Millard and Ryan Eatmon were there after presenting their tutorial, and chatting with them is what put a bug in my ear about all this). The Jabber community has long valued independence, so much so that we lack cohesion. Sure, we've got a great technology (it still blows my mind that Jer thought up the whole idea of streaming XML), but we're not really working together to build out the potential of our technological foundations. We changed the focus from code to specs at a certain point and now we lack the momentum we need as an open-source community (as distinct from a technology community). The Jabber pioneers were able to make so much progress in 1999 because they were a small, focused group that pursued separate projects (jabberd, Winjab, Gabber, Net::Jabber, etc.) but worked toward a common vision in a coordinated way. We can't duplicate that success now, but we can emulate it with appropriate changes for the "modern" Jabber context.
Perhaps one strong server group and multiple client groups will work better than a single client effort. I think that a single client is worth trying, and I think Python is the way to go for server, client, and library. Who would work on these inter-related projects? Lots of folks seem interested. Who would pay them? Perhaps we can aggressively seek donations, either through the JSF (if these are sponsored projects to build reference implementations) or independently, either from corporations or through grants. Would this Python initiative stifle innovation? I don't think so -- in fact, existing servers and clients would probably be spurred to greater heights by the competition. Would a stronger open-source community challenge the commercial XMPP vendors? You bet it would, but I think the focus is different and we need a vibrant open-source codebase to provide reference implementations and safeguard the openness of the protocols.
Naturally we can talk about this forever. The key is to get active. One research topic on the client side is wxPython (there are tutorials and howtos and getting started guides and cookbooks and wikis galore). For the server, we probably need to look more deeply into whether Twisted is the way to go. Perhaps the first step is to write a really good Python library: while there are several existing libraries, they are all pretty low-level, whereas I think we need to build something that encapsulates lots of functionality for developers and doesn't force people to build or grovel through various IQ namespaces (though it should allow developers to do their custom stuff, it support all the draft JEPs out of the box -- note that the list of Draft JEPs will be much bigger by the end of the year if I have anything to do with it). The goal should be to write a library that is worthy of inclusion in the Python Standard Library (see PEP 2), even if it takes a while to achieve that level of maturity and acceptance.