Don’t use that open API — it could be a trap!

In case we needed another lesson in the vagaries of the “open” APIs that are offered by web companies for developers to build features around, Facebook has provided a perfect example by shutting down the API for, the facial-recognition service that it acquired last month — even though the company said after the deal was announced that it wasn’t planning to do this. When combined with the recent rumblings about Twitter and its plans to further restrict use of its API by outside developers, the incident is a welcome reminder of how open APIs can suddenly become a lot less open, and startups (and users) can get trapped in the middle.
When Facebook’s purchase of for a rumored $60 million was first announced, the service said that it valued its developer community and planned to continue to support them, implying that the API would remain untouched. But as The Next Web reported on Saturday, the facial-recognition startup sent an email to developers saying that as a result of the acquisition by Facebook, it would no longer be able to support the API or the developer network. To some developers, this seems a bit like the company saying: “Thanks for helping us build a company so we could be bought by Facebook — now get lost.”

Building on another company’s API is a huge risk

Twitter has suffered a similar backlash from developers and other observers, after a blog post from the company’s director consumer product announced that the service was planning to tighten the rules around its API. As we explained in a recent post, the news triggered such a negative response in part because the company has been aggressive about doing this in the past, and many developers seem a little gun-shy about their status as part of Twitter’s “ecosystem.” Some have stopped developing for the service at all, and some angel and venture investors say they have lost interest in such opportunities as well.
This isn’t an issue that affects only Twitter, of course — it is a Faustian bargain that applies to plenty of other companies as well. Amazon has cut off third-party services such as Lendle in the past, and Google recently started charging for APIs such as its Google Maps API, which likely threw a large wrench into the business plans of a number of startups and outside services. As blog and podcasting pioneer Dave Winer put it in a recent post, the lessons that should be drawn are obvious:

Smart developers will not just conclude that Twitter is unsafe to build on, but also any company that is operating in the Twitter model. If they are running a website, and trying to attract a lot of users, and are going in the direction of advertising, you’d be a fool to think they won’t do the same as Twitter has.

One of the reasons why Twitter’s behavior has caused so much backlash is that — as Reuters blogger John Abell and others (including us) have noted — much of the foundation for the company’s estimated $8-billion market valuation has come from the same third-party apps and services that Twitter no longer seems interested in supporting. Using those tools, users came up with most of the features we now take for granted, including @ mentions, the idea of re-tweets, and the the whole concept of hashtags (which are quickly becoming an advertising tool). And now some developers seem to feel as though they are being tossed aside after outliving their usefulness.

Open APIs are a double-edged sword

What the and Twitter cases reinforce is the dual nature of an open API, as entrepreneur Syed Iqbal noted recently: it can be an incredibly useful tool for other startups, especially if it allows them to tie into a larger platform or network — such as Twitter, or Google, or Facebook — and take advantage of the size and reach of that partner to grow more quickly. And for the platform company itself, all of those developers and outside services can add value relatively quickly (and cheaply) to the network.
The flipside is that when a network or platform gets large enough, as Twitter has, having all those tiny developers and outside services can seem more like an unnecessary bug than a crucial feature — especially if the company wants (or needs) to take control of some of those external features and apps in order to monetize its network effectively. Is this just a natural process, in the same way large predators consume smaller ones, or one species grows so quickly it squeezes out another?
In a recent debate on Branch, a startup that offers hosted invitation-only discussions, a couple of former Twitter staffers — former product VP Jason Goldman and former lead engineer Alex Payne — defended the company’s actions by saying they believe such moves are more about developing a standardized consumer experience than “evicting” outside developers (an explanation that echoes the Twitter post that started the recent controversy).
Entrepreneur Narendra Rocherolle, however — an earlier advisor at Twitter who developed the service’s original mobile app and was the first to post a re-tweet — also made the point that by tightening the reins on its ecosystem too much, Twitter could be giving up the benefits of a more open approach. Alex Payne has also made this argument in the past, including in a letter he sent to Twitter’s management after leaving the company in 2010, in which he said the service needed to “become more decentralized or die.” The full Branch debate is embedded below:

Post and thumbnail images courtesy of Flickr users Steve Jurvetson and See-ming Lee