Marco.org

Twitter announced yesterday that third-party apps will have their access to direct messages (DMs) revoked at the end of the month, and the apps that need DM access — any full-featured Twitter clients, except Twitter’s own — need to start requesting a new type of OAuth token if they still want to use DMs.

And these tokens will only be issued in OAuth web-browser flows, not xAuth, so apps need to pop up little web-browser windows or kick you through Safari for you to log in, rather than the common xAuth practice of just showing a simple username-and-password form in the app.

Oh, and one more thing: formerly-xAuth apps that need DM access have only 12 days to build this completely new login interface, test it, and release a new version — and, for iOS and Mac App Store apps, get it approved — before their existing apps start being denied access to DMs and probably display confusing and incorrect error messages, since the developers could never have foreseen this condition. Such aggressive timing is definitely a dick move.¹

Twitter’s official announcement of this change begins:

The Twitter ecosystem contains hundreds of thousands of interesting third-party applications designed to enhance your Twitter experience. Third-party apps let you do things like automatically share your Tweets on other networks, connect to other players on gaming platforms, or instantly tweet whenever you update your blog.

Translation: “Add-on or piggy-back apps are what we consider ‘third-party applications’ now. We will not acknowledge any other application types. There is no such thing as a complete Twitter client by someone other than us, as far as we’re concerned. If you choose to develop one, we will not make it easy for you, and we can and probably will kill it in the future at our convenience.”

This isn’t news. Ryan Sarver at Twitter bluntly said almost exactly that two months ago.

Full-featured clients are completely dead to Twitter. Gone. Invisible. Like most web companies, they prefer a clean break. Down the memory hole. These apps never even existed. Doesn’t matter if they helped make Twitter popular.

It’s easy to look at this DM policy change as a sleazy way for Twitter to make third-party clients worse, as John Gruber speculates:

I can’t think of any reason why Twitter would force native apps through OAuth other than to create a hurdle that steers users toward Twitter’s own official native clients. Because Twitter’s official clients aren’t going to force users to jump through OAuth to authenticate — they’re still going to simply ask for your username and password in a simple native dialog box.

There’s actually a very good, pragmatic, non-evil reason for them to do this: they want to make sure that people know what permissions they’re granting the app before they click that big green OAuth “Allow” button, and the xAuth flows used so far in most clients don’t give Twitter a chance to explain to users what level of access is being granted. In other words, Twitter wants to control the messaging. And that’s understandable, although misguided.²

Twitter couldn’t possibly care less about the inconvenience this causes for third-party client developers.

And that’s also understandable, for three big reasons:

1. It’s not that big of a deal.

This isn’t a huge problem for most Twitter-app developers. (Most Twitter-integrated apps aren’t full clients and don’t even need DM access, and therefore don’t need to do anything. This is only a pain for full-client developers.)

The 12-day deadline sucks, and there’s no reason for Twitter to be so aggressive with it. But in a few months, everyone will forget about any problems that result from it, and we’ll all have time to flame Twitter for whatever changes or requirements they force next.

2. Twitter is not ours.

Twitter can do whatever they want.

It’s the simple, brutal truth. Twitter must do what’s best for Twitter. They owe us nothing.

It’s not a public good. It’s not a right. It’s a private, entirely centralized service with no meaningful competition and a massive network-effect barrier to competitive entry. Twitter has all of the power in its relationship with users and developers.

It doesn’t matter whether third-party clients helped make it popular. Twitter has reciprocated for years by giving such apps a compelling platform for which to sell software. Successful Twitter-client developers have made a ton of money in exchange for the help they provided in making Twitter popular.

It was a fair deal to both parties, but Twitter believes that they no longer need this help and they can reap many benefits from controlling the full client experience, so developers of other full clients are being cut out of the deal.

3. Twitter is unstable and constantly changing.

Twitter is a huge service with correspondingly huge operating costs, a staff of hundreds of people, major problems and constant shuffles among the founders and leaders, and just barely enough revenue to be profitable (as far as I know) after raising $360 million in funding.

It’s a very different company today than the Twitter we knew a year ago. This wasn’t a devious change — it was forced to transform based on its sheer scale. But many of the people who made Twitter that developer-friendly company have since left or become burdened by an influx of other employees above and below them.

The old Twitter is gone. The new Twitter is faster, bigger, much more stable, full of Javascript and dysfunctional hash-bang URLs, and much more interested in owning the clients that most people use. And next year’s Twitter might be radically different from today’s.

You can’t count on anything about Twitter to remain constant.

The entire company — and, by extension, the product and the API — is in constant flux. What’s there today might not be there tomorrow.

And because of point number 2 above, they don’t need to get our permission or give us much warning before changing or taking away something that we like or depend on.

These are the risks that you take when you base your personal happiness or your business on a single, irreplaceable, young, evolving third-party service.