11436 SSO

Caveat structor - Builder Beware: Twitter's API policy clarification

Sam Ramji
Mar 21, 2011

Twitter unleashed a firestorm this week by announcing a change to their API policy for apps that enable users to read and write tweets.   

Their announcement is not a big deal – it effectively says, “simple clients to send and receive tweets are core.  Don’t go there. And don't copy our experience.”

This is actually the right type of communication from a platform company.  You want them to say “There are risks for you here as we’re building stuff.  We would like to see further innovation in this other place over here.”

This is always the case with platforms – they focus on what is core, and over time what is core grows

The communication from Ryan Sarver suggested that a large percentage of Twitter apps exist in the area they’re identifying as core.  This created misinterpretations like “Twitter’s killing their API!” 

But’s not a large percentage.  The broad majority of Twitter applications are not simple read-write clients, but analytics, brand management, social CRM, and marketing. (see the oneforty.com visualization below)

What you need to plan for as a developer, is that an API is not the same as a dependency on a library.  You’re depending on a service that can change, grow, shrink, or cease to exist.  You’re getting tremendously more functionality than we ever got out of libraries.  It makes sense that the risks are also larger and must be managed.

One of these risks is the Terms of Service (TOS) for an API.  They don’t freeze in time like the license for a library.  They can and will change to meet the needs of the business that provides them.  In the library era, Microsoft provides a few examples of what a major platform provider with an expansionist philosophy could do:

  1. Compete directly by selling similar software (Microsoft Office vs. Corel et al),
  2. Compete indirectly by including similar software in the platform (Wolverine vs. 3rd party TCP/IP stacks),
  3. Compete based on TOS or legal action (barring 3rd party developers from using “private Windows APIs” under trade secret law).

We’ll see Twitter do all three over time as well – they’ve already done #1 (acquiring Tweetie and releasing iOS and Android clients) and just now #3 has been demonstrated again, just as it has been in the past with barring 3rd party advertising.  #2 is probably not far behind – for example, it only makes sense to start offering analytics functions that currently come from some 3rd party services and apps in the Twitter API core in order to increase adoption of the Twitter platform for business and marketing apps.

Where there is cause for optimism is that single-function, single-API apps are becoming the historical part of the apps + APIs phase of this next Internet. 

Apps that do something useful for the user across a domain – say social messaging for consumers across their channels, like TweetDeck and Trillian – are real products that enable a whole use case.  A narrow app like something that crawls Facebook and shows me what movies my friends recently watched is not a whole use case.  One that combines it with Fandango for ticketing or Netflix for instant viewing, or IMDB to let me learn about the graph of actors, directors, and movies related to the movies my friends watched are whole use cases.  These kinds of apps will also be more resilient to API changes because they are less dependent on any single one.

I come not to praise Twitter for their platform strategy, nor to bury them.  This changed nothing about the API economy.  It simply showed another scene in the same movie we’ve been watching all along.  We’ll see more of this from more providers over the coming years, as the next Internet evolves and companies compete for monopoly positions in their domain.  Hopefully for them, they'll learn from Twitter's communication failure and not alienate their developer communities as they do so.

And as always in software: caveat structor will apply.

Scaling Microservices