Yesterday Twitter released a new set of guidelines to developers on what to build on their platform. In it, they took a pretty radical view at what is arguably the most popular type of application to build: the “mainstream consumer client”. There are easily hundreds, if not thousands, of these apps on the Twitter platform. However, as of yesterday, the official line from Twitter is “don’t build these apps any more”. This has upset a lot of developers of exactly this type of app (and validates my theory that getting out of writing Streamlines was a good idea!). This announcement will have a chilling effect on innovation, and will permanently and irrevocably destroy any semblance of trust remaining between developers and Twitter.
Looking Back at Third Parties
When Twitter launched in 2006, there were two ways to interact with it. The website (which has now come to be known as #OldTwitter), and SMS. There was no Twitter client, no desktop experience, and no mobile experience. Oh, and they had an API. For the non-programmers in the audience, this API basically consists of a standardized way for apps to contact Twitter and get data in and out. Just about every Twitter app (client or service) you’ve ever used has used Twitter’s API to do its bidding.
People started using Twitter’s API to build apps. One of the first and most notable is Twitterrific, which launched around January 2007. As the lead developer, Craig Hockenberry, notes in a blog post made yesterday, Twitterrific was responsible for many innovations like:
being the first Twitter client for both Mac and iPhone,
being the first to use the word “tweet” (which is now actually trademarked by Twitter),
being the first to use a character counter in a tweet composer
In mid-to-late 2008, Loren Brichter of Atebits released Tweetie for iPhone, a pretty universally loved Twitter client (for good reasons). He released version 2.0 in 2009. In that time, he added a ton of innovation, including (among many other things) the now-ubiquitous pull-to-refresh interface concept, which is now pretty much standard on Twitter clients, but also lots of other apps (including Facebook’s own).
I’ve highlighted these two, because I’m a Mac/iPhone guy, but they’re hardly alone. Many other Twitter clients that are out now have innovated on the Twitter platform to deliver something greater than the sum of its parts. Millions of people rely on the power and flexibility of TweetDeck to carve out the relevant portions of the social networks it consumes, for example.
All of these innovations were driven by third parties, not by Twitter. In fact, most of these apps pushed Twitter into implementing features which improved the user experience, such as retweets and conversations.
Looking Back at Twitter
Twitter has always been plagued by performance problems. Going back to their launch, they’ve had constant downtime and slow-to-respond APIs. They’ve made improvements, but you can ask anyone who uses Twitter that they’ve still got a long way to go. Instead, they clearly seem focused on shoveling features into their platform. Over 2009, they added several features, including retweets, lists, and geolocation. Each of these were adopted by users quickly, who insisted these features be present in clients. These features were largely added with no real prior announcement or technical information given ahead of time. Most of these features were written once, and then summarily never improved again. Issues still exist with retweets and blocked users, and lists still have the same limitations as when they started.
In 2009, Twitter decided to change up how they authenticate (how a call to the API knows that I’m @SteveStreza and not, say, @WhiteHouse). They switched from basic auth (which sends your account’s password to Twitter on every request) to a system called OAuth (which sends a “token”, which pairs your account to a specific app, to Twitter on every request). This in itself is a Good Thing, because it makes it harder for a malicious app or person to steal your password, and makes it easier for you to cut off apps you don’t trust any longer.
However, Twitter’s roll-out of this feature was very botched. Their initial implementation required that all users get sent to a web page, where they entered their password. This design was geared towards web developers, not desktop/mobile developers. As a result of this, implementing OAuth was a terrible user experience for those environments. Due to the poor user experience compared to basic auth, existing clients waited until the very last minute to add OAuth support to their clients, while new apps (which HAD to use OAuth) suffered a competitive disadvantage with a hostile login process. Many clients could not even be written; certain cell phones had such poor web browsers that they couldn’t even display the login page necessary. A year later (February 2010), they finally fixed this by introducing XAuth, which allows mobile/desktop developers to present their own UI for asking users for passwords. And in August 2010, the cut the spigot off for basic auth.
But in 2010, everything changed. In April 2010 (not even a year ago!), Twitter acquired Atebits and made the formerly paid app free, under the branding “Twitter for iPhone”. They also released Twitter for Android. In September, they launched #NewTwitter, a new version of the Twitter.com website (which had previously had incremental improvements and feature additions). In the beginning of January 2011, they released Twitter for Mac. But the glue that holds this all together: in April 2010, Twitter announced their Promoted Tweets ad platform.
Over the course of one year, where Twitter was encouraging people to develop these kinds of apps, they completely undercut the existing market by putting free apps on a variety of platforms, with no prior announcement about any of this.
Twitter recently introduced the #dickbar (or, officially, the “Quick Bar”) to Twitter for iPhone, which forces you to look at whatever trending topic (promoted or not) they’d like. After the backlash, they backpedaled and made the feature, to quote a friend, “less annoying” (it’s still a user experience nightmare, but now it’s somewhat less so!). Then, a couple days later as users abandon the official app for third-party clients, Twitter releases a statement “discouraging” developers from writing their own apps.
Instead of building the “mainstream consumer client”, Twitter says developers should focus on other kinds of services that interact with the Twitter API. Their recommendations include things like “brand insights” tools and “social CRM” apps; the kind of stuff that makes self-described social media gurus cackle but makes actual engineers vomit. They say to build enterprise tools, when they are already building enterprise tools. Their messages and their actions are completely out of sync.
Twitter’s intentions have always been packing more functionality into their platform, and informing developers about it as late as possible. As Wayne Gretzky said, “you skate for where the puck is going to be, not where the puck has been”. Twitter’s made it impossible for developers to have any insight on where they should aim. They provide conflicting messages about their intentions. But most of all, they introduce a level of uncertainty about what it is they’re building. Uncertainty kills innovation; if someone doesn’t know what the rules are going to change to tomorrow, they won’t invest time and money in building something today.
What I Think Twitter Should Do
In-your-face forced promotion and shutting out 3rd-party players is endemic when you take money from advertisers, not users. But many of these users (myself included) are intrinsically tied to the real time social network, and would gladly pay in a heartbeat for value added to the service, as opposed to degraded user experience. Certainly not all, but a significant portion.
Consider the model recently adopted by Reddit, a system called Reddit Gold, where users who pay for the service get perks like extra features and access to early features. On top of that, the service is now answerable to the users who pay the bills, not the advertisers.
To do some calculations, Twitter now has over 253 million unique users per month visiting their site. If 1% of those users were willing to pay $5/mo for the service without ads or promoted tweets, they’re looking at a revenue of $151 million dollars per year based on the users they already have who want to pay for this. This is over 3x what they earned in 2010 on ads. These users are the ones who will be deriving the most value from Twitter the service, and will be the least likely to be effected by in-app advertising. They can keep Promoted Tweets and Trends on for those who don’t pay. iPhone app developers use this technique all the time; the app is free with ads, or spend a few bucks to remove the ads. These numbers may be higher than reality, but there is a lot of opportunity for Twitter to bake value in at the service.
Additionally, Twitter should focus more on improving the core infrastructure of their service. Their constant downtime is pretty hard to accept four and a half years later. Removing some of the limitations (like the 20 lists or the ability to only access your most recent 3,200 tweets) would be welcome as well; the black box of data that Twitter has stored is massive, and users want the ability to be able to access their own data (hence apps like TweetLibrary which fill that void by maintaining their own database). When Twitter has actually built up their service to the point where it is reliable and not so terribly opaque, they will have a more convincing argument that they’re prepared to handle a unified user experience.
However, it may be too late. Twitter has broken trust with their developers far too many times; the developers who helped build Twitter’s platform from a micro-blogging service to a cultural phenomenon. Whether anyone will innovate on the Twitter platform any more is yet to be seen, but I doubt it.
I think I’m pissed off at Twitter’s announcement today because the wording makes me feel like I’m be lied to and taken for a fool.