Developers, bracing themselves for Twitter API restrictions, call today’s post “ominous”

Twitter’s success has long been intertwined with the independent developers that have chosen to use the platform. The third-party ecosystem made Twitter what it is in the most literal fashion possible.

That’s why there has been some consternation over a post on Twitter’s developer blog today that coincided to the minute with a post going live on the LinkedIn blog. The gist of the posts was that Twitter was cracking down on how third parties were using its APIs. LinkedIn’s display of the entire Twitter feed in its users profiles was the first casualty of this new stricter interpretation of the rules, but it won’t be the last.

Specific portions of the post by Twitter product team director Michael Sippey stood out to me, and to many Twitter developers. Specifically, these two passages provide a very interesting juxtaposition:

Back in March of 2011, my colleague Ryan Sarver said that developers should not “build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” That guidance continues to apply as much as ever today. Related to that, we’ve already begun to more thoroughly enforce our Developer Rules of the Road with partners, for example with branding, and in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used.

And this one:

We’re building tools for publishers and investing more and more in our own apps to ensure that you have a great experience everywhere you experience Twitter, no matter what device you’re using. You need to be able to see expanded Tweets and other features that make Twitter more engaging and easier to use. These are the features that bring people closer to the things they care about. These are the features that make Twitter Twitter.

Note the mentions of expanded Tweets. No client I know of utilizes that functionality as of now besides the web version, not even Twitter’s own mobile apps. Twitter said that it had no comment beyond what it said in the post.

I polled a few high-profile developers who use the Twitter platform and APIs and the general consensus was that the wording of the post was ‘ominous’. That was a word I heard a lot, though everyone seemed to want to stay off the record for now, in fear of upsetting the already wobbly applecart.

In the early days, the third-party ecosystem was a playground, in which developers could, and did, come up with uses for the service that were never intended or dreamed of by Twitter itself. You like the word ‘tweet’? The bird icon? The character counter? The replies and conversations features? A nice native client on the iPhone? All done first by third-party developer Iconfactory with its Twitterrific app.

Heck, the users themselves came up with ‘RT’ and it was incorporated by third-party clients like Tweetie before it was added to Twitter itself.

So why, since then, has Twitter not had the easiest of relationships with the third-party community? There are a lot of answers to that question but, in the end, it all comes down to money.

Twitter has undergone a period of intense growth lately and, for the most part, has shown itself to be handling that growth well. Unlike a lot of folks, I feel that the recent changes to Twitter, including the additions of the Explore tab, email newsletters and other enhancements, have been in the best interests of growing, retaining users and teaching new ones the value of the service. Among those changes has been monetizing in a variety of ways, including serving ads on the site and in the timeline through its mobile apps.

One of the biggest possible reasons that Twitter could be more tightly enforcing restrictions on its API, especially in cases where a stream is represented outside the first-party clients, is to control its advertising stream.

But even that isn’t a serious issue for most third-party developers that I’ve spoken to. Some of them have even expressed a desire for Twitter to just come out and be honest about wanting them to serve up ads in all feeds, inside the official ecosystem and out. They said they’d feel safer knowing that Twitter had set forth specific rules and regulations regarding advertising in the firehose, as that would be one less reason for them to have their access shut off.

There are a dozen other ways in which changes to the API could affect developers, however. Restricting the rate limits on the home timeline would limit the amount of tweets that outside clients could display in a given time period, making them useless for power users. Direct Messages could have restrictions placed on them to either block access or limit the amount kept or sent.

In the end, there are a lot of unknowns, and that’s what is keeping these developers up at night. And it’s not as if they haven’t been given any reasons to worry either. Many have felt that their products were threatened by Twitter’s statements that they should steer away from building clients and the blocking of third-party ads from streams.

The seed for a lot of those worries was planted with the same developer’s forum post back in early 2011. Later that year, Twitter founder Jack Dorsey posted a message that thanked these third-party developers for their efforts and promised more communication and a continued relationship.

But a lot has changed with regards to Twitter’s strategies over the 11 months since then and it has continued its move towards being a mainstream information service, rather than a geeky power tool. For the most part, it’s done a good job, but its attitude towards third-party developers is once again in question and it has those developers worried.

And if you’re someone who uses Twitterrific, Tweetbot, Osfoora, or any of the other ‘standard’ Twitter clients I’d be worried too. Because if there’s one thing they were designed to do and do well it is “mimic or reproduce the mainstream Twitter consumer client experience.”

And that’s something that Twitter just may not feel it has room for any more.