This is an open letter to all people related to the content of this article. So, you better read everything to see if that includes you ;-)
Instant messaging clients like Pidgin, Adium, Miranda and Kopete combine support for different instant messaging networks in one program. They often also support platforms that are not supported by the official client software. Therefore, these so-called multiprotocol clients are seen by many as a good thing for interoperability. However, I strongly disagree on this. Instead, my analysis sounds the opposite way:
In this article, I will explain these tough claims. Also, I will elaborate about a possible strategy for those who would like to get rid of closed non-interoperable instant messaging networks. In short this strategy is simple: we need to render the walled gardens pointless by destroying the reason they are more profitable than open networks.
In this section, I will tell you why multiprotocol clients do not help much to fight closed networks. Not much, as a lot of resources are wasted in these projects which could otherwise be used in a more effective way to get rid of closed networks in favour of open networks. Without closed networks there would be a very friendly and innovative environment suitable for the emerge of "the Firefox of instant messaging".
Ok, but what is the right way to fight closed networks? The right way is a combination of several dedicated XMPP clients with some darn good transports. Transports are server-side gateways that allow XMPP clients to connect to closed networks without any significant effort like reverse engineering or designing a multiprotocol architecture. To be more clear about this abstraction, transports translate the language of the XMPP client to the language of a client on a closed network without the XMPP client knowing that language.
Time for the core of this article...Why transports matter:
The quality of support for open standards like XMPP is lower in multiprotocol clients than in dedicated XMPP clients. This can be easily explained by the increased complexity of the software to support multiple protocols, but this is only a minor point that can be solved by having enough eye balls to catch bugs. More important is the fact that XMPP is less used by geeks compared to popular closed protocols. Hence, there are more eye balls looking for bugs in closed protocols support than to catch bugs in XMPP protocol support.
Compare this with instant messaging clients dedicated to the open standard protocol XMPP. First, these clients don't need a complex multiprotocol software architecture. Second, their reason to exist is XMPP support. Thanks to this dedication, the quality of XMPP support is more likely to be much higher than that of unfocused multiprotocol clients. A bug that breaks XMPP support is a major issue in XMPP clients whilst it is a less major issue in multiprotocol clients as these clients will still be usable for other protocols.
Transports matter because they force end users whom mostly use closed networks to contribute their "eye ball capacity" to XMPP support.
The 'instant messaging experience'(or innovativeness) of multiprotocol clients is lower than that of the official clients for the closed networks. They run behind because of the required reverse engineering, the complex software architecture, and the tendency to only support features common to the majority of supported popular networks. They tend to limit their feature set to the least common denominator of its constituents, which can be very small. They cannot influence the future of the underlying protocols as these protocols are controlled by the companies owning the closed networks. Where is the room for innovation? There is no room for this as multiprotocol clients simply can never take over the lead of the official clients in designing the future of the closed protocols.
Dedicated XMPP client projects instead, fully focus on a single protocol that is extremely well documented and thus don't needs any reverse engineering. Moreover, XMPP client projects can have their say in the future of the underlying protocols and even can propose their own protocol extensions for standardisation. That's an open door for unlimited innovation!
Transports matter because they allow XMPP client projects to fully focus on innovation without losing interoperability with closed networks and without being influenced or hindered by the closed networks. Transports allow XMPP clients to lead the instant messaging world, instead of following the closed networks owners, like multiprotocol clients tend to do. The later can be compared with Mozilla: no focus, complex, not sexy, following the leader(s), not popular, and so forth. The combination of dedicated XMPP clients and transports could become like Firefox: focused on open standards, innovative, taking over the leadership position, very popular, and so forth.
The image of open source multiprotocol clients hurts the broader open source image. Open source multiprotocol clients do not lead in their environment and are seen as poor extracts of the official clients. Unfortunately, this poor image of being a follower instead of a leader means the public will associate open source alternatives by definition with poor extracts of the real thing. Hence, people even may not try XMPP because of earlier unsatisfying experiences with multiprotocol clients.
Choice on closed networks is created by multiprotocol clients. Multiprotocol clients allow people who for some reason cannot or do not want to use the official client to connect to closed networks. This choice also reduces the vulnerability of closed networks to malware. You may think these are all good things, but in fact they hinder adoption of open standards like XMPP.
Imagine a world without alternatives to official clients for closed networks. All people who are today contributing to the multiprotocol part of multiprotocol client projects would focus on XMPP and server-side transports. Client projects wouldn't be forced to do urge releases due to some compatibility change in the closed network protocol. Development would be totally independent from the closed network owners. Focus can be directed to innovative client features in the XMPP world. All end users using one of these clients in combination with transports would use XMPP. So, every user would contribute to the maturity XMPP, even if they only want to communicate with people on closed networks!
Transports matter because they can lead to more and higher quality choice in the XMPP world. More choice because the existence of very good transports make it more interesting to create XMPP software. Higher quality because all end users will use the XMPP code, even if they only use their XMPP client to connect to closed networks.
Flexibility of multiprotocol clients is extremely low. Multiprotocol client projects are bloated. They need testers for all integrated protocols. The complexity of the multiprotocol architecture needs maintainance. Large changes in the support for one protocol are not easy if this could break support of other protocols, and if they make such changes they have to do this very carefully. Multiprotocol client projects tend to first add features common to all integrated protocols instead of adding innovative features.
Compare multiprotocol client projects with XMPP client projects. Look at the number of innovative protocol features in multiprotocol clients compared to XMPP clients. Also consider how many coders are involved in the different types of projects. The following statistics from ohloh.net about contributors over the entire history of the project can help you. Of course, these numbers are not 100% accurate at all (e.g. some projects give translators commit rights whilst others don't), but still, the significant differences give an indication:
|Multiprotocol Clients||XMPP Clients|
|Pidgin (33), Kopete (100), Adium (52), Miranda (22)||Coccinella (3),Tkabber (2), Psi (7), GOIM (5), Spark (10), Gajim (19), JWChat (3), Bombus (1), Freetalk (4)|
The fact that there are more active dedicated XMPP clients in the wild than there are active multiprotocol clients says a lot about the required community size to sustain a less complex but focused XMPP client.
Transports matter because they move the maintenance burden and release burden (no forced releases) away from the client projects. They increase the projects' flexibility and development speed (less and shorter testing periods, less complexity). They move away the eventual legal issues in some countries from the client project to a server project which is more suitable to benefit from today's globalised world. A country eventually can forbid multiprotocol clients, but it never can forbid inhabitants to use a transport service hosted in another country without being punished with a trade war by other nations as this would be a trade barrier in services.
Multiprotocol clients should become single protocol clients. To accomplish this goal I propose to "steal" community of multiprotocol client projects in favour of XMPP software so that their 'community resources' will become insufficient to sustain a complex design for multiple protocols. We also can ask them to drop support for closed protocols, but I'm afraid they will just laugh at us.
To "steal" community of multiprotocol client projects, he reasons why end users chose multiprotocol clients should be eliminated. Currently, I see two constructive ways to do this:
Help the Wine project to support the official clients. In this way, the hard task of reverse engineering and maintaining the proprietary protocol code becomes less urgent for people who contribute to multiprotocol clients, and they may stop doing their hard work. Also, end users will be more happy on their new platform as they can stay using the client they are used to. They can use all features of this closed network...including all misfeatures of the client. If this end user wants choice, he has to install an XMPP client.
Note also that official instant messaging clients for closed networks are strategically an interesting target for the Wine project. Instant messaging clients are probably the most important application of younger people. These people like to experiment with new operating systems. However, they face huge switching costs as they cannot run the instant messaging client their friends use. The switching costs are higher if they need to use an alternative client as they need to learn a new interface for their most important application, and because the alternative multiprotocol client probably does not has all features of the official client.
As a side note, you can see why the Mac OS X version of Windows Live Messenger can't be compared with the Windows version. You also see one of the reasons why Microsoft will not adopt XMPP soon: it hinders youngsters to switch to non-Microsoft platforms. But if the Windows version of Windows Live Messenger can fluently run under any platform thanks to Wine, Microsoft loses a good reason to not adopt XMPP. Note that I do not say they will per se adopt XMPP afterwards!
More and better transports are needed to allow XMPP clients to compete effectively with the key feature of multiprotocol clients: interoperability with multiple closed networks. Multiprotocol clients can't innovate as fast as XMPP clients can (see above), so we can tackle them on the interoperability feature which is XMPP's core feature.
Currently, there is lot's of room for improvement of transports in XMPP land. Because transports are a key feature in the success of Coccinella and other XMPP clients, we would ask the broader XMPP community to improve the current situation regarding transports.
Wishlist for transports:
Focus on reliability of service: uptime, hot code update, fail-over, clustering to bypass blocking, and so forth.
Focus on reliability of compatibility. Fast deployment of fixes for protocol updates by the closed network owner is what we need. The faster transports are updated, the more expensive and thus the less interesting it becomes for closed network owners to change their protocols to block alternative software.
Focus on basic interoperability features only. Text messaging and presence should be the focus. Other features are not important and only make it harder to maintain "reliability of compatibility".
More closed networks. Transports should cover all closed networks.
XMPP based ideology. Transport projects should favour the XMPP world in the first place. "What XMPP feature will I map to the closed network today?" instead of "What closed network feature will I map to the XMPP world today?" XMPP protocols should be written first and only after that we should look if they can be mapped to closed networks, we should not write XMPP protocols to get similar features as the closed networks have. Taking the lead means not copying features, instead it means innovating with unique protocol features.
Also, transports should be friendly only to people on the XMPP side of the gateway. People on the other side of the gate should get what they have chosen for: no openness, no help, and a bad experience. For example, an error message should sound "You cannot send this file to your contact because your software is not interoperable. Please contact <name of network owner> for more information." instead of "You cannot send this file to your contact because your contact does uses an XMPP client. Please consider switching to XMPP to fix this issue.". When the XMPP user wants to send a file to his contact on the closed network it should sound: "We are sorry but this file cannot be send because your contact uses a chat system that is not interoperable. Please consider to ask your contact to switch to the open XMPP. This issue cannot be fixed without the help of the closed network owner. May we therefore also ask you to sign the petition on <URL>? By supporting this petition, you ask the owner to open its closed network and by this offering a better service to you. This interoperability issue can't be fixed without their help".
As you can see, with a difference in approach we can forward all troublesome interoperability experiences to the real responsible instances (the owner of the closed networks). In this way end users will not associate the issues to XMPP and they may even understand open standards fanboys! This can mean a big thing for the image and popularity of XMPP.
No lock-in feature of a server. As is normal in good open standard communities, any lock-in is seen in the XMPP community as evil because it is bad for the emerge of the open standard. Lock-in also can be the root of a software monoculture. We also don't want that. Luckily, server projects are making their components compatible with other servers. And hopefully, this server will follow soon. But we are not there yet.
Shaped to die fast. Transports' main goal should be to die as fast as possible. If a transport project dies it may mean the related closed network became open or went offline! Transports should be tools of judo strategy:
The central message of Judo Strategy is that [instances] facing more powerful opponents should avoid head-to-head struggles and other trials of strength. Instead, by employing speed, agility, and creative strategic thinking, they can shape the dynamics of competition in ways that prevent rivals from taking full advantage of their superior strength. At its most effective, judo strategy can even transform an opponent’s apparent advantages into strategic liabilities that undermine his or her ability to compete.
Sexy software. Transports should become sexy software projects with a nice website, good documentation, a good community, easy installation and configuration, and so forth. But this item is obvious :-)
In case you want to argue on my thoughts, consider all next facts before you reply: