It was announced yesterday that Facebook Chat is soon going to use the open standards XMPP. This means that in the near future you will be able to use Coccinella and any other XMPP client to connect to Facebook Chat. We don't even have to provide you with a new Coccinella release, thanks to the merits of open standards.
When reading this great news, I remembered that not so long ago Adium and Digsby announced support for Facebook Chat. Obviously, the support they added is for today's closed Facebook Chat protocol, not for tomorrow's XMPP based service. Both applications already support the open instant messaging standard XMPP since long. This means that these projects would have had support for Facebook Chat anyway if they just had a bit more patience. I wonder how frustrated these developers currently are, now that they know that their brand fresh code will become obsolete even before it gets in a stable release.
So, in fact, instead of using their scarce time to implement sexy new features that are interesting for all their users, Adium and Digsby developers wasted their time to support a walled garden protocol of which the wall fell ultra fast. I must admit that I now have a small grin on my face :-)
However, I also have a bad feeling. What if not only Digsby and Adium were so fast in adding support for the closed Facebook Chat, but also others such as Pidgin, Trillian and many others? Would there still have been enough pressure on Facebook to make the decision to switch to XMPP so fast? I guess XMPP support wouldn't have been that urgent for Facebook any more.
I hope these developers have learned their lesson: never add support for new walled garden networks to your client. Wait as long as possible and direct all requests from users who are requesting support for a new walled garden system to the owner of walled garden. If you don't do this and try to attract users away from other instant messaging clients, by adding support for a walled garden network, you may get frustrated when this network switches to XMPP. Plus, your support reduces the pressure from users on this walled garden network to open its entrances. All in all, what you thought was a feature, in fact is a misfeature.
If waiting not helps to get a walled garden to show its flowers to the public, you can better use server-side XMPP transports. Transports have several strategic advantages over native client support, they provide basic interoperability to please your users, when shaped to die fast they don't lead to much frustration, and they do not lead to competition amongst multi-protocol clients based on the numbers of walled gardens they support. Better compete on *real* features.
To conclude, I also hope that developers who are still adding new features in multi-protocol clients for the Yahoo and ICQ/AIM protocols are aware that they can experience the same frustration as described. Indeed, these two walled garden networks are already experimenting with XMPP.
The future is XMPP. Walled garden networks are finally getting a thing from the past!