Twitter Ye Not?

19 Aug 2012

Anyone who’s been paying attention to Twitter (the company) will have been waiting for the other API shoe to drop, and yesterday it did, landing squarely (but not unexpectedly) on developers using their API. In summary, Twitter are continuing their strategy of limiting the the types of application that can connect to the service, and the things that they can do once they’re there. Some of the changes are mundane book-keeping (requiring authentication for all API calls, shuffling around the rate limits), but others are more pervasive. Marco Arment, developer of Instapaper, summarises most the key points, and objections, here. He finishes with this:

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.

Given the changes in the API, this seems like an eminently reasonable position. When you depend a proprietary (as in, owned by a single company) API, you’re to an extent at their mercy. When their interests align with yours, everything is fine, and everybody wins. However, as soon as their interests diverge from yours, you’d better have a back-up plan. I plan to write more about that in the future, but today I want other questions.

Do I think this is a mistake on Twitter’s part? Perhaps; it seems that they’re sacrificing a lot of good will for short-term gain, and uncertain short-term gain at that. On the other hand, I don’t know the internal details of Twitter’s business, and I certainly can’t predict the future, so it’s entirely possible that this will turn out well for them, and provide enough of a revenue stream to justify their considerable funding.

Is this going to make Twitter a poorer service? Undoubtedly, yes. The wealth of clients, the simplicity of the core service, and the multitude of services built on top of that core, are all big reasons why I prefer Twitter to Facebook. Discouraging (and, eventually, banning) “traditional” third-party clients, limiting the services that can be built on the API, and cluttering up the stream with inline media (“Twitter Cards”) all work against these advantages.

Are you going to stop using Twitter? This is the big one, hence the title of this post. And, in the tradition of headlines ending in a question mark, I’d say the answer is no.

I joined Twitter fairly early, before anyone else I know, in order to follow interesting people (emphatically not celebrities, who hadn’t heard of it by this point) like @gruber and @timbray. Since then, many more people have joined, including many people I know personally. Nevertheless, the attraction of the network is the same. Interesting people, saying interesting things, are what makes a social network interesting (the meaning of “interesting” varies from person to person, of course). Hence, I’m going to stick with Twitter while it’s still the place where interesting things are happening, in spite of their recent attemprs to undermine the experience.

Does this mean I’ll never leave? No. If the conversations I want to be a part of (or, at least, eavesdrop on) move elsewhere, I’ll go with them. This is the real risk that Twitter is taking; not that their API changes will scare everyone off immediately, but that they will contribute to a soft but steady pressure pushing people away. Social networks don’t die with a bang of closed accounts, but with a whimper of irrelevance.

This site is maintained by me, Rob Hague. The opinions here are my own, and not those of my employer or anyone else. You can mail me at rob@rho.org.uk, and I'm @robhague@mas.to on Mastodon and robhague on Twitter. The site has a full-text RSS feed if you're so inclined.

Body text is set in Georgia or the nearest equivalent. Headings and other non-body text is set in Cooper Hewitt Light (© 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License). BBC BASIC code is set in FontStruction “Acorn Mode 1” by “p1.mark” (licensed under a Creative Commons Attribution Share Alike license).

All content © Rob Hague 2002-2024, except where otherwise noted.