The case for the Twitter API changes

Lots of people are upset about the API changes that Twitter announced on Thursday afternoon. John Gruber summarized the announcement as “Twitter to Client Developers: Drop Dead.” Others reacted similarly. While I am not necessarily for the API changes, I think it is worth carefully examining why Twitter might want to impose these rules on its service before rushing to judgment and blowing $50 on another company that might do the same thing down the road. On closer examination, Twitter’s actions are not really any different from Apple’s practice of restricting who can run OS X and what features can be added to apps in the App Store—and they are motivated by the same logic.

Twitter says that they want “to deliver a consistent Twitter experience.” Why might they want to do this? My guess is that they have run some user experience tests. They have probably rounded up some people who have never used Twitter before and, without much hand-holding, asked them to sign up for Twitter and start using it.

Let’s say that one of the testers has an iPhone. He goes to the App Store and searches for Twitter, where he finds the official client and several third-party clients. Maybe he downloads the official client, maybe he lingers over some of the third-party ones. Probably he’s not interested in the paid clients at first.

On the App store, the first result for “Twitter” when I searched just now is the official client. The second is Instagram, which is not a Twitter client. The third is a free, third-party Twitter client, TweetCaster. I have not used TweetCaster, but it looks terrible. Check out the screenshots, and especially, do not neglect the ones for iPad. They are truly atrocious.

You can do a similar exercise in the Android Market or in the Mac App Store. The plain truth of the matter is that most Twitter clients are terrible. So a new user goes to one of these stores, downloads a crappy Twitter client, and that determines (part of) his initial impression of Twitter. These crappy clients impose a negative externality on Twitter, by polluting the user experience of their least savvy users. And Twitter doesn’t have to live with such pollution.

Twitter is laying the groundwork for pulling the plug on the TweetCasters of the world. But developers will get angry if they just start canning all of the apps that are ugly or don’t work properly. So they are setting up rules well in advance explaining what they expect of client developers. They have been warning for months for developers to use caution when starting a new traditional client. This is because they plan to impose some high standards on the clients that they allow to continue to use their service.

The makers of Tweetbot, by far the best Mac and iOS client, have written a post about the API changes entitled “DON’T PANIC.” Neither Tapbots not Tweetbot users have anything to worry about, because Tweetbot has a good user experience and Tapbots is competent enough to stay in compliance with Twitter’s guidance.

I think that part of the panic about the API changes was driven about the “cap” on user tokens. In the announcement, Twitter wrote that client developers “will need our permission if your application will require more than 100,000 individual user tokens.” Reuters misreported this statement as “Under [Twitter’s] new rules, independent software developers who create new Twitter apps will only be allowed to have a maximum of 100,000 users.” But it seems highly unlikely that Twitter will refuse permission to any application that plays nicely with the user experience requirements.

Twitter’s restrictions on developers is a straightforward example of what is known in the economics literature as “vertical restraints.” In the classic article on the subject, Klein and Murphy look at the case of Coors’s unusual distribution practices in the 1970s. Coors used an aseptic brewing process and its beer was not pasteurized. As a result, the beer required extra care to be taken during distribution: it needed to be refrigerated at all times, and stock needed to be rotated out every few weeks. Coors took some unusual steps to ensure that its distributors complied with its rules, because if they did not, consumers would have a bad experience and who would they blame? Not the distributor, who was actually at fault, but Coors itself.

These vertical restraints are common in the technology world. Apple does not allow third-party computer makers to distribute OS X. Why? Because when a user has a bad experience on lousy hardware, Apple doesn’t want to get the blame in the consumer’s mind. Similarly, Apple is quite restrictive about what iPhone apps are allowed to do. Apple doesn’t want some app running in the background and draining the battery, because then users will blame Apple, not the app developer.

People like John Gruber understand the value of Apple protecting its reputation. But aren’t these new developer requirements just an instance of Twitter doing the same thing? Twitter has a very legitimate need to ensure that its ecosystem is not polluted with crappy third-party clients. These new requirements are just an early step in the process of cleaning it up.