Gnip Says XMPP Ecosytem Too Half-Baked, Pulls the Plug
There's no more riding through the transit station on roller blades - the rental shops aren't keeping them in good enough repair. That could be an analogy for a decision announced today by Gnip, a startup aiming to become the ultimate ping server for social media.
XMPP/Jabber, the Open Source real-time communication protocol popularized by Instant Messaging that many have hoped would serve as foundation for a real-time web of the future, has become too much trouble to support and will no longer be a supported protocol at Gnip. More than just one protocol, it's a story of long tail developer communities and the ambitious startups forced to make resource decisions.
Gnip founder Eric Marcoullier told us that the company really wants to support XMPP but that it's taking up an inordinate amount of support time, in many cases just because data consumers are using Google Talk or Jabber.org servers and are being throttled.
Marcoullier says there are simply no open source Jabber servers that are capable of the kind of robustness that a social media ping server requires. If a major vendor came to Gnip and said they wanted data streamed to them exclusively in XMPP, the company would continue the practice, but the long tail of tiny consumers that want their data that way is taking up too much resources. The company's top priorities are data delivery and maximizing the number of publishers participating in their program.
Our top priority as industry watchers is to cheer for radical innovation online, something that is in some cases more likely to come from the marginal developers making up the Long Tail that Gnip is herein limiting its support for.
Does This Matter?
This move may be less significant than it seems, though, too. The real-time communication experience is still available via basic Restful push, Marcoullier says, but for now XMPP in particular will be turned off this week.
When Gnip launched, we thought that XMPP in particular and protocol transformation in general were key to its value proposition. Months later, the company says that there is data normalization occurring but no protocol transformations are being performed.
Gnip now has a total of five developers, most recently adding enterprise data specialist Michael Barinek onto the team. The company has significant momentum even if today's announcement feels like it's losing some sexy sheen.
We hope that Gnip can continue to advance its goals of making the social web faster and more scalable. While we're disappointed that this hyped protocol is giving them too much trouble, we hope that a future web of real-time communication can come to us promptly none the less.
Share
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
Why is our industry soooo slow to adopt XMPP. The reason is MSN, Yahoo, Skype and several others have lovely closed protocols that they don't want Google and others to play in. As one Yahoo senior exec told us there is no commercial pressure to support open standards like XMPP in Yahoo Messenger.
I hope once openid, dataportability and the other open standards stack layers are adopted we as an industry will turn our attention to realtime communication interoperability.
Until then I guess the best we have is longpolling/restful push.
The question is if XMPP can be made into an efficient application for streaming events to multiple (or multitudes of) suppliers. I am afraid this is not simply a matter of a bette rimplementation of an XMPP server but something much more fundamental. Roy fielding has argued (http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons) why this is not possible and why the solution is simply to better structure the HTTP APIs that the various services provide. The economics for XMPP simply do not work for this application. This is why large customers are needed. There is cost involved and somebody has to pay it.
Marshall -- thanks for helping to spread the word. We don't want folks to be surprised on Wednesday when outbound XMPP goes dark.
To be clear, we haven't said XMPP is half-baked. It's a badass protocol with huge potential. Sadly, the individual open source implementations are still fairly nascent (half-baked, you might say) and as a result many people (includig our own developers) aren't having stellar success running them.
Anyone capable of running XMPP is probably already running a web server, which means that we can still push to them data in real-time. In other words, they get the benefit they're looking for, just not the specific feature.
"You can't always get what you want, but if you try sometime, you just might find, you get what you need" -- Mick Jagger
This is more of a meta-comment. I was only mildly interested in this news because a) am mildly interested in Jabber/XMPP and b) I've never heard of gnip and don't really care about it. So when I got to the paragraph that starts with "This move may be less significant than it seems, though, too," I stopped reading. An already insignificant post was declaring itself even less significant.
I mean, if this move is insignificant then why write about it?
Josh, thanks for taking the time to comment anyway! And nice to make *your* acquaintance. :)
I'm surprised they weren't able to make any of the Open Source XMPP servers scale to their needs -- definitely not what I've seen with other services. If that's truly the case, it sounds like there's some work to do.
By taking away XMPP, gnip will no longer have the ability to push updates to end points that are behind a firewall (HTTP pushes won't work through a firewall typically). Perhaps that's not a big problem for their developer base.
It's always smart to focus on the areas of functionality that are most important so I'm sure Gnip is doing the right thing for the service. The unfortunate thing is that XMPP support is still in a chicken/egg hold pattern for the real-time web and it's going to take some additional momentum to break past the logjam.
So is there a blog post in the past somewhere that lists the various "real-time web" scenarios??? I mean, beyond "Twitter updates" and blog comments??? I love the sound of the idea, but want some concrete examples too... thanks.
thanks.
It's interesting that just as gnip turns their xmpp feeds off, Fire Eagle is releasing code and starting to test turning them on.
http://github.com/mojodna/fire_hydrant/tree/master
Clearly webhooks are simpler. But they also have scary scaling problems associated with them as well.
I was afraid this would happen. But greed and all attempts to "vendor lock" us out of our own data won't put the genie back in the bottle. If it isn't Gnip, we'll find something else.
David Gelernter's vision WILL happen, there's no stopping it.
http://java.sun.com/developer/technicalArticles/Interviews/gelernter_qa.html
I think Gnip should have a tag line of something like Social Data router
Twitter already turned off its interface so there is nothing new here. If its going to create a more stable platform for us developers then I am all for it.
Great service in the making.
Darren, we've used the "router" term before to describe Gnip. I think it fits nicely. In its "distributed" form, where notifications are routed around various "Gnip hubs" it makes perfect sense (note, we haven't implemented that outside of our cluster yet :-) ). I like your thinking.