Twitter unleashed a firestorm of concern and criticism this week by announcing a change to its API policy for apps that enable users to read and write tweets. Its announcement is not as earth-shattering as commonly portrayed. It effectively says, ‘Our core business is sending and receiving tweets. Using our API to re-implement our core business is no longer valid.’ At its heart, this is the right type of communication from a platform company. You want them to say, “There are risks for you in this area. We would prefer to see innovation in this other area.”
This is always the case with platforms – they focus on what is core, and over time what is core grows. The company announced that it does not want to see more development of apps that “mimic or reproduce the mainstream Twitter consumer client experience”. This was a stronger position than Twitter had taken previously, and showed that it plans to expand on these capabilities as part of its core business.
What it didn’t do well was communicate clearly, which created big opportunities for misinterpretations like “Twitter just told its third-party client application developer community that it is no longer wanted.” The communication from Twitter’s Ryan Sarver suggested that a large percentage of Twitter apps exist in the area it is identifying as core. But it’s not a large percentage. The broad majority of Twitter applications are not simple read-write clients, but analytics, brand management, social CRM, trending, sharing, and marketing apps.
What you need to plan for as a developer is that an API dependency 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. As a developer, if you don’t have a plan for this, you should. You’re getting tremendously more functionality than we ever got out of libraries – an entire service, with data, updates, users, and scalability that you don’t have to pay for. It makes sense that the risks are also larger and must be managed.
Twitter’s announcement highlights one of these risks: 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. Even in the library era, Microsoft (s msft) provides a few examples of what a major platform provider with an expansionist philosophy could do:
- Compete directly by selling similar software (Microsoft Office vs. Corel et al),
- Compete indirectly by including similar software in the platform (Wolverine vs. third party TCP/IP stacks),
- Compete based on TOS or legal action (barring third party developers from using “private Windows APIs” under trade secret law or code obfuscation).
We’ll see Twitter do all three over time as well – it has already done No. 1 (acquiring Tweetie and releasing iOS (s aapl) and Android (s goog) clients) and just now No. 3 has been demonstrated again, just as it has been in the past with barring third-party advertising. The second item is probably not far behind – for example, it only makes sense to start offering analytics functions that currently come from some third-party services and apps in the Twitter API core in order to increase adoption of the Twitter platform for business and marketing apps. No doubt there are new ways to compete in the API economy that have yet to be cataloged.
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. They represented part of the first wave of API-based applications and helped us understand how to use APIs. By contrast, apps that do something useful for the user across a domain – such as messaging for consumers across their IM and social channels, such as TweetDeck, Seesmic, and Trillian – are real products that enable a whole use case. These create lasting value and a community of users around the app itself, which is good for both the developer and the API provider.
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 (s nflx) 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.
Twitter’s move simply exposes a facet of the API economy that has been true all along. We can expect to 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 the large API providers will learn from Twitter’s communication failure and not alienate their developer communities as they change.
And as always in software: caveat structor (developer beware) will apply.
Sam Ramji is Vice President of Strategy at Apigee, a company that manages APIs. Prior to Apigee, Ramji led open source strategy across Microsoft.