My Twitter feed is full of worry about the changes to the Twitter API. (Yes, that probably means I should unfollow a few people so that it gets back to the baseline of "I'm eating a sandwich".) Here's some of the notable problems that people see with the new rules, which are going into effect over the next 6 months.
From Marco Arment, creator of Instapaper, "Interpreting some of Twitter's API changes" is a good overview of the challenges for a developer to comply with new rules while still innovating on their core application. His conclusion is stark:
Twitter has left themselves a lot of wiggle-room with the rules. Effectively, Twitter can decide your app is breaking a (potentially vague) rule at any time, or they can add a new rule that your app inadvertently breaks, and revoke your API access at any time. […]
I sure as hell wouldn’t build a business on Twitter, and I don’t think I’ll even build any nontrivial features on it anymore.
And if I were in the Twitter-client business, I’d start working on another product.
The new App.net has grand designs to be a Twitter clone, based on three elements: a solid realtime engine for data, a well defined open API, and a subscription supported model (rather than an advertising supported model) for making the whole thing pay. Dalton Caldwell's manifesto is a worthwhile read, "Announcing an audacious proposal"
I believe so deeply in the importance of having a financially sustainable realtime feed API & service that I am going to refocus App.net to become exactly that. I have the experience, vision, infrastructure and team to do it. Additionally, we already have much of this built: a polished native iOS app, a robust technical infrastructure currently capable of handing ~200MM API calls per day with no code changes, and a developer-facing API provisioning, documentation and analytics system. This isn’t vaporware.
Not surprisingly, the alpha.app.net channel is full of want to be superstar application developers figuring out how their new idea could work in this new space.
There are two applications that I use that could be affected by this set of changes. One is Pinboard, which is a bookmarking tool that (among other things) reads and archives my Twitter stream. Pinboard's developer Maciej Ceglowski has a very funny, no holds barred Twitter account for Pinboard, where he among other things promotes his own service by retweeting posts from the accounts of his competitor Delicious. Here's his take on app.net:
I'd be sad if my Twitter backups didn't work.
The unusual Twitter client that I use which is most likely to run up against the new look-and-feel guidelines of the Twitter API is ttytter, a command line client written in Perl by Cameron Kaiser. It looks nothing like the official Twitter apps of any kind.
It's hard enough to insist on API and look-and-feel rules with applications that are user configurable; imagine what it must be like to enforce those rules when the application is delivered as relatively easy to modify source code. How can you make sure people don't break the rules if they can change their own code?
Twitter has some reasonable reasons to want to narrow the scope of what third parties can do with their service, but it's not going to come without a fight. Expect a tug of war between innovation and conformity, and it's safe to say that some of that innovation that comes at a high cost and low value to Twitter will be squashed out. I'll be particularly interested in the delicate balance between value provided by Twitter to advertisers (who pay directly) and social media marketers (who often ride for free) on the service.
Edward Vielmetti's Wordpress weblog 