Walled Gardens Response

14May08

Sander recently wrote about Facebook’s announcement that they would be exposing their new chat features via XMPP over at the Cocinella blog. I’m very happy to hear that another large company is planning to support open standards, and I completely agree with Sander that we should avoid walled gardens. However, I did have some comments on other parts of his post.

Regarding Digby and Adium adding proprietary Facebook chat support, Sander wrote

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 if this is really true. If Facebook was so interested in XMPP, why didn’t they start with that? Surely it’s easier to start with XMPP than to write something else and then create a gateway. Perhaps they had no intention of an open garden, but later relented after they saw the cat was out of the bag with several clients getting Facebook chat support so quickly. Maybe we have these client authors to thank for this announcement?

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.

This is a real concern. I hope they aren’t so frustrated that they don’t bother making the new XMPP based Facebook chat nicely integrated. It would be terrible if people continued to use the proprietary protocol when an open one is available. Maybe Facebook will shut off the wall garden once the XMPP support is in place. I definitely wouldn’t want to support two protocols.

Sander suggests using XMPP transports instead for access to proprietary networks. He’s written about it seperately as well.

Transports have several strategic advantages over native client support

While this is true, I think current transports lack in a lot of areas, and certainly I have not seen an XMPP client that has as nice an implementation of transports and transport set up as the multi protocol clients have for their proprietary networks. I think everyone agrees that the XMPP technology is better, but so far the developers (myself included) have not yet made this a win for users.

So let’s welcome Facebook into our community of open instant messaging standards, and let’s continue to improve the transports and the support for transports in the clients to lure those poor users living in the walled gardens.

Advertisements


3 Responses to “Walled Gardens Response”

  1. 1 Jason

    Actually, I wouldn’t be surprised if open XMPP support was Facebook’s intention all along. The Facebook Chat “protocol” is really just bits of Javascript allowing you to chat from a browser, since browsers don’t speak XMPP — you can’t even open sockets without using plugins like Flash or Java. It was never intended for any kind of use outside the browser. What they’re doing now is opening Facebook Chat to outside clients and (presumably) networks.

  2. 2 metajack

    @Jason: That could be. I certainly did not know any details about the Facebook chat protocol. However, browsers can speak XMPP thanks to BOSH. We use this quite extensively at Chesspark.

  3. 3 sander

    I wonder if this is really true. If Facebook was so interested in XMPP, why didn’t they start with that? Surely it’s easier to start with XMPP than to write something else and then create a gateway. Perhaps they had no intention of an open garden, but later relented after they saw the cat was out of the bag with several clients getting Facebook chat support so quickly. Maybe we have these client authors to thank for this announcement?

    My point is that instead of starting to code without thinking, it would have been better for these projects to sustain user pressure on Facebook to adopt XMPP by ignoring the new walled garden, at least. If both Adium and Digsby would have ignored Facebook Chat, the pressure on Facebook from users who want to use Facebook Chat in their favorite standalone client would only have been stronger and thus it would have been even more important for Facebook to add XMPP support very fast to please their users. So, boycotting new walled garden networks is the way to go: these networks are all too small to push their own proprietary protocols and *all* popular instant messaging clients already support XMPP. If multi-protocol clients stay competing on which new walled garden networks they support, we will never get rid of them (the walled gardens, not these clients).

    This is a real concern. I hope they aren’t so frustrated that they don’t bother making the new XMPP based Facebook chat nicely integrated. It would be terrible if people continued to use the proprietary protocol when an open one is available.

    Well, I don’t think that will happen: who wants to maintain an inferior and duplicate interface? Only fools would do that and I’m sure the Adium/Digsby devs are no fools.

    I think current transports lack in a lot of areas,

    I will not deny that; but things can change 😉

    I have not seen an XMPP client that has as nice an implementation of transports and transport set up as the multi protocol clients have for their proprietary networks.

    We worked on improving the integration of transports in Coccinella (and have more ideas!), maybe you should try our latest release. Feedback about how we can improve Coccinella in this regard is always welcome!



%d bloggers like this: