Twitter published the overview of version 1.1 of the API yesterday. Lots of space and many words have been devoted to why their changes are hostile to developers of Twitter-based applications (and they certainly are). For background on the changes and how they affect developers, the best opinion posts I have seen are this one by Daniel Jalkut on the OAuth token restrictions, and this one from Ben Brooks on what the changes indicate about Twitter on a corporate level.

(For additional reading, see Marco Arment’s exposition of the changes and Tapbots’ initial reaction juxtaposed against their pulling the Tweetbot beta.)

I think what’s been overlooked in all this is how some of the changes—maybe the most influential and important ones—are actively hostile towards users of the service. They place burden and unnecessary restriction on the very users that Twitter is looking to court and retain to turn the wheels of their business model.

I’ll preface this by saying that I am very much a layman, so my understanding here may be flawed. If you can correct me and convince me that it’s really not all that bad, please leave me a comment and let me know.

Abandoning Open and Accessible Standards

Once upon a time, Twitter supported the use of RSS as a method for grabbing information from your timeline and even updates from one or more users. In fact, when I first started using Twitter myself and third-party clients didn’t exist yet, RSS was how I consumed timeline information.

For some time now, RSS has been pretty well hidden, but you could still access it and use it if you wanted to even though it was unsupported.

No more:

We’ve chosen to throw our support behind the JSON format shared across the platform. Consequently, we’ve decided to discontinue support for XML, Atom, and RSS, which are infrequently used today.

This is a page out of Facebook’s strategy, where I would love to be able to grab RSS feeds or groups and friends who basically use it for blogging, but I can’t—or at least I can’t figure out how. JSON is still a standard and it’s still open, but your data is getting less and less accessible all the time.

In version 1.1, we’re requiring applications to authenticate all of their requests with OAuth 1.0a. Not only will this visibility allow us to prevent abusive behavior, but it will also help us to further understand how categories of applications are using the API. We’ll apply that understanding to better meet the needs of developers as we continue to evolve the platform.

Let’s be clear; by “further understand” they mean “tightly control.”

On Twitter, your updates are “public,” but they are “public” only insofar as Twitter wants you to be able to display them. By curtailing methods of pulling data that can be used without authentication, and controlling tightly who can and cannot authenticate to the service and how many times, it allows Twitter to eventually trap your data.

I believe that even with these changes, public timeline data can be queried without authentication via JSON, but JSON tends to be less end-user-accessible than at least Atom and RSS. I can still access my timeline RSS now, but I will assume that this will change when Twitter deprecates API 1.0.

Token Limits

This is what a lot of the hubbub has been about from a developer standpoint, and to be fair, developers do end up with it being their problem. But users are the eventual target of this restriction.

All applications replicating the core Twitter experience, usually called “clients”, will have some new restrictions placed on them, including a 100,000 user token limit.

So when an application has hit its limit, how is that supposed to be communicated to the user who requests token 100,001?

Do you—

• Wait until your token counter hits a certain limit pre-100k, then pull your app from distribution (thus alienating users who want to evangelize your app to friends and others who want to try it)?
• Display an error message to users 100,001 and beyond (who will probably blame you anyway and not use your app even if you get more tokens)?
• Furiously blame Twitter for the limit in either a status message or page on your app’s website (potentially confusing users even more)?

The point I am trying to make here is that even though the developer is the one who is hamstrung by the token limit, the users of the app are the ones who face the messaging and confusion. The users are the people who are told that their choice to use a client that isn’t the core Twitter experience is the wrong choice and isn’t permitted.

I am sure this is intentional on Twitter’s part as a nudge to get as many users as possible to use the “official” clients. (Which, let’s remember, started as third-party apps in most cases.) But from the users’ standpoint, something will just appear to be broken. Whether the user decides to blame the developer of the client in question or the Twitter service as a whole, it’s limiting choice—and worse than that, it’s limiting choice in a way that wasn’t limited previously.

A lot of users probably won’t care or notice, and I seem to recall seeing stats recently that indicate that the number of Twitter users who consume the information on Twitter via non-official clients is actually quite small. But for those savvy enough, it’s going to be annoying.

In the end, I think it’s the wrong move for Twitter, and it’s the wrong move for Twitter’s users. Personally, I am using Twitter less and less as the crazy around it increases. And I’m pretty sure I won’t be the only one.