Dare Obasanjo has an excellent post up titled Sharing social activity streams across the Web: How Gnip fits in. In it he supports the move from pull to push notification, but questions the reliance on one provider, such as Gnip, as a single point of failure (SPoF).
It’s clear that there is a need for both pull and push notification. Right now the web 2.0 space is quite lacking in the push notification arena.
However, I don’t see much problem of a lock-in or SPoF issue because the Gnip behavior will be abstracted itself into proxy libraries that let you switch between data providers. You’ll be able to run your own Gnip type thing if you want to move away, or switch to any alternate provider. You’ll see a federation of these things, so, for instance, Flickr will co-locate a Gnip type server in their data center that will provide similar services. As an application developer you will configure your remote data transport system in a kind of ring-down way where you try Gnip first, Gnip clones, then per-service Gnip-like servers ala Flickr’s colocated service, then per-service direct API’s in case of larger faults. As the same time, all of this will be happening in a ‘virtualized’ Gnip service running on your own servers.
What you’ll pay for is bandwidth, QoS, etc. It will be a commodity market where the top players provide extended services that larger startups/companies demand such as reporting, global fault tolerance, application optimization services, etc.
The opportunity here, especially for Gnip, is to be the first mover that establishes not just the standard, but signs up big companies in a strategic lockup that reinforces their position and standard. Everything is still open, but it will be harder for new entrants to propose alternate standards and methods. A well capitalized Gnip will be in a position to have enterprise IT departments make long term (5-10 year) technology bets that include lucrative support contracts. Scrappy me-too competitors will have a harder time making this happen.
Along these lines, I suspect that the real dollars are going to be found in the thousands of Salesforce API implementations. Twitter and Flickr are sexy, and might get pulled into Salesforce, but in general there are way more many internally developed applications that need this kind of thing than there are web 2.0 startups willing to pay enough to make it a business. Ditto the above on broad B2B data transports — the type of stuff that has replaced EDI, including the EDI over XML derivatives, could really utilize a service like this. The best way to engage all the startups is actually to open up the Gnip system more to allow 3rd parties to flush out the support of APIs to include everything on the web.
Under the scenario above, it makes sense to look at companies like Cisco, IBM, and Salesforce as potential suitors.
Cisco’s take would view this as part of the network stack (ie, Gnip is a web 2.0 API switch), and additionally would see its potential to increase bandwidth usage on corporate networks by making it very easy for people to consume more data than they do now. This is important — while Gnip might reduce the total data bits that would have been transfered by a factor of 10-100 to 1 or even more, it ultimately has the potential to increase the absolute aggregate number of bits people decide to actually transfer due to ease of use, etc. More bandwidth consumed means more Cisco routers sold.
For IBM, it is a consulting play. Every cash register is going to connect to multiple services in the cloud and someone needs to be there to do the integration and hold the client’s hand. If you can charge other companies a ‘gateway fee’ to get visibility on the cash register then that is an additional revenue stream. There’s nothing stopping IBM from charging a store to access Twitter while also charging Twitter for access to the store because in this scenario IBM owns the platform which is the cash register; not the store, not Twitter, and not an API aggregation service.
Re: Salesforce, it’s the obvious industry player to do this given their incredible success of business use of their API which they estimate will far exceed use of their user facing web application. Helping people connect more services to their Salesforce accounts increases utilization, dependence, and thus lock-in for Salesforce. Additionally, it would allow Salesforce to engage the consumer centric web 2.0 community, potentially developing a new source of leads for their business services. The danger is that Salesforce may choose to release their own Gnip like service.
I guess I have to mention that it would make sense for Amazon to do this also as it is a perfect complement to their web 2.0 platform play they are executing against.