Twitter Won't Kill the API

This guest post comes from Adam Green, a Twitter API consultant who Builds custom Twitter apps for clients, and blogs about Twitter programming at Follow him at @140dev.

Let's get real about Twitter's plans for their API. Even though the New York Times claims that Twitter wants to "kill" its API and developer ecosystem, and some competitors demand that Twitter data is too valuable to society and must become part of an open, federated infrastructure, neither of these things are going to happen.

Twitter is not free, and it does not belong to its users. It is a business that belongs to its investors. Turning off the API or giving away Twitter's competitive advantage over its data would hurt Twitter's chances of going public eventually, so it is a certainty neither of these "ominous" events are part of Twitter's plans. We should all accept that the people running Twitter aren't stupid, and turning off the API is a stupid idea.

What Twitter's leadership is guilty of is being extremely clumsy, and consistently failing to understand how its developers earn their living. Announcing that you will announce changes that could affect every Twitter app in "the coming weeks" is the definition of clumsy communication. It also proves that the people behind this announcement have no idea of the economics behind professional development. I've been earning my living from Twitter API development for 3 years, so I can fill Twitter in on the secret they keep missing. Developers earn their living from clients. Sure some devs are just script kiddies trying to learn how to tweet from a PHP script for their own thrills, but the developers who count make money by building apps for clients and tool users who pay them. The last thing paying clients want is uncertainty, and the fear and doubt that the apps they are paying for will not exist in a few weeks is the worst kind of FUD.

As I just said, that isn't going to happen, but Twitter's clumsiness has once again caused the predictable firestorm of worries. The really sad part of this miscommunication is that the clumsy ending obscured the real point of the blog post. If you read it closely, you will see some interesting points that have been completely lost in the current frenzy:

  • "... we want developers to be able to build applications that run
    within Tweets."
  • “What you’ll see us do more and more as a Platform is allow third
    parties to build into Twitter.”
  • "... we’re looking forward to adding new ways for developers to do
  • "... we’re hard at work building tools that make it easy for developers
    to build common Twitter features into their own sites"

Does this sound like an announcement leading up to Twitter turning off the API or sending out "eviction notices for third-party apps"? Of course not. So why did we get such extremely scary coverage of this post? Because Twitter devs are scared all the time that their work will be turned off arbitrarily, and with no recourse. It is a constant fear, and as anyone who follows the Twitter developer lists knows, a sad reality. Twitter is at war with thousands of malicious apps at all times. They are so busy fighting off the bad actors, that they sometimes reflexively include the good guys in their warnings. They can't seem to help making threats, and we can't help being scared of what's coming next.

The solution is simple. Don't try to tell us how much you like us, Twitter, while holding a big stick behind your back. You may not think that "stricter guidelines around how the Twitter API is used" is scary, but the minute I read that, I knew this was going to get ugly. Here's an idea. If you have good news or want us to support a new feature, ask us nicely, and save the threats for another post. It should be clear that threatening everyone, especially in such a vague way, is going to be all anyone sees or talks about. Even more important, Twitter, if you have bad news coming, don't announce that you are going to announce it some time in the future. Just yank off that band-aid. Get it over with fast. The reality is never as bad as the anticipation.

Be sure to read the next Best Practices article: Need a Robust API? Try Scala