Twitter has a problem. It wants to deliver a “consistent” experience for its users, and as we’ve seen over the past couple of weeks, third-party clients don’t appear to have much of a place in the company’s vision of the future.
Sure, Twitter first announced its distaste for third-party clients last year, but in the light of the recent LinkedIn incident, the threat of our favorite apps getting killed off seems all the more real. This has led to concern across the blogosphere, especially as tech bloggers aren’t generally the type of people to use Twitter’s official apps.
Do business with 5,000 people
TNW NYC is our New York technology event for anyone interested in helping their company grow.
It’s an issue that’s flared up today in some of the discussion around the alpha launch of Tweetbot for Mac. The initial response to the app has been great, but tainted by a sense of worry that Twitter may shut it out of using the API at some point in the future.
Here’s the conflct, in a nutshell…
Twitter wants to:
a) Control the way its product is presented to its users.
b) Ensure it can monetize its user base, something it can’t do if they opt for apps with features like Tweetbot’s ‘mute’, or which may not play ball when it comes to displaying advertising.
However ‘power users’:
a) Feel that Twitter’s own interface isn’t the most effective way of consuming Twitter content – that’s why they use third-party apps and even the otherwise abandoned Adobe Air-based version of Tweetdeck, which is far more feature-rich than the native desktop version released after its developers got acquired by Twitter last year.
b) Appreciate the purity of a simple 140-character Twitter experience, something that Twitter itself is trying to move beyond with expanded tweets that contain news reports or other forms of media.
So, how do we solve the problem?
The solution is a ‘Twitter Preferred Developer Program’.
Twitter may not be keen on third-party clients, but a noisy subsection of its userbase is. Twitter could pick a small group of the best third-party apps, hold them close to its bosom and work with them.
It would hold these apps to strict standards – Twitter’s Promoted products for advertisers would have to be supported, and developers would have to commit to integrating any future monetization drives too, perhaps on a revenue sharing basis.
In return, Twitter could promote these apps as approved alternatives to its official apps and shield them from a wider cull of apps that it simply doesn’t want its users exposed to. Similar to Apple’s iOS developer program, there may be a small fee in addition to a degree of handpicked selection by the developer relations folks at Twitter, but this would let the chosen developers into a ‘protected circle’ of support for their endeavours.
As Dave Winer recently put it, “Twitter is a corporate API“, and we can’t expect the merry days of five years ago, when its ecosystem was a playground of unbridled experimentation, to return. Twitter simply has to have as much control of its ecosystem as possible. However, it can and should throw a bone to the best client developers and their users by building them into its future.
Between first-party-only, locked-down consistency and the playground of the past, there’s a third way – and Twitter should take it.
Image credit: Phines†