Cisco Acquires Jabber.com

Wow – now this interesting
http://www.techcrunch.com/2008/09/19/cisco-acquires-jabber-for-enterprise-im/

I wonder what this means in the long run for the open development of this platform?

Just to be clear - they have acquired Jabber.com the company not Jabber.org the open XMPP standard.

So I guess they have bought 'developer expertise' and bums on seats by buying the company, and apart from obviously 'bringing industry and investor attention' on the other development companies in the space (Jive, Openfire,Tigasse etc) I'm wondering what this means for the long term.

As some of you know I've been working on a XMPP based website that I'm going to be looking for an 'A' round of funding in January next year so I'm not sure what this means for us at the moment.

BTW for those of you who dont know what Jabber is there is a great explanation on the ReadWriteWeb site below

Jabber Explained In Simpler Terms
In simple terms and to the best of my understanding, the http protocol used by web pages is said to be inefficient because it requires a user's machine to poll a server periodically to see if any new information is available.

Quite often there is nothing new and energy has been wasted. Think of how often Gmail checks to see if you've got any new emails (every two minutes) or how many times your RSS reader pings all of your feeds to see if they contain any new items. Meanwhile, the time between polling leads to a delay in updates.
That might seem like a small burden to you, but multiply that times everyone using these services and there's a lot of inefficiency. Sometimes that inefficiency can define the technical limits of what a service is able to do. On an individual level, I know I'm unable to use Google Reader because I have enough subscriptions that it times out checking every single one of them for new information. I wish it would just chill out and wait!
This is not a problem experienced in the world of Instant Messaging. While there are too many IM protocols in the world, a growing number of IM clients, including Google Talk, use the open standard Jabber, or XMPP.

XMPP lets one party signal to any XMPP server that it is available to receive any new information that's being delivered. When another party sends new content through the XMPP server, the message is passed on immediately and automatically to all recipients who are marked as available, basically.


There are also some major benefits to be gained when building data backbone platforms, eg trading desk applications where information is being 'sourced' from a site and updated across multiple interfaces.

One of the more innovative uses I've seen for XMPP over the last few months is the use in a web based game that chess moves are communicated via xmpp to ajax based web clients.

So i get that Cisco didn't buy jabber.com engineers to implement a Cisco IM platform for their retail clients and that they must have something much bigger in mind.

You could possible see different cisco devices communicating with each other (or even using an api to communicate with other manufacturers devices) eg, you might have an XMPP api to 'discover' appliance functionality or to communicate status updates.


Cheers,
Dean