Twitter dropped a bombshell on third-party application developers last Friday — the social network built on the backs of third-party developers and clever, innovative clients has decided it no longer needs them.
Twitter’s blog post is short on specific details, but the gist of it is that Twitter is tightening up its API access for third-party developers. The company has long viewed third-party apps as unnecessary and previously warned developers not to “build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” But thus far it hasn’t enforced that guideline. Now it seems it will.
In a post on the Twitter developer blog titled Delivering a consistent Twitter experience, Michael Sippey, Twitter’s director of product, seems to say that the company wants its official clients — and only its clients — to be the way people use Twitter. Instead of building clients that pull out of Twitter, the company wants developers to “build into Twitter.” In other words, kiss your Tweetbot, Twicca or Hibari goodbye and get ready for some embedded widgets instead of good ol’ tweets.
Much digital ink was spilled over the weekend denouncing Twitter’s policy change or lamenting the potential loss of alternative Twitter clients. Of course Twitter is in charge of Twitter and when you use its service — or build apps on its API — you must suffer its whims.
But Twitter’s decision to start enforcing its API restrictions “more thoroughly” could end up a great thing if it inspires developers to take the essence of what makes Twitter great — succinct, timely messages to and from your friends — and free it from Twitter the company.
An independent and decentralized equivalent to Twitter is certainly not a new idea. The basic building blocks you’d need to build such a system have been with us for many years — a combination RSS, OPML and perhaps PubSubHubbub would cover of most of it — but until now there hasn’t been widespread client developer support for such a system. After all, why go to all the trouble of building a decentralized network on top of open web standards when using the Twitter API is so much easier?
Twitter’s third-party developers now have the answer to that question — because you can’t be locked out of the open web.
Developer Brent Simmons, perhaps best known for creating the Mac-based RSS reading app NetNewsWire, has a basic outline of how Twitter app developers could band together and make something that not only sidesteps Twitter’s coming API restrictions, but the service itself.
“The interesting (to geeks like us) part,” writes Simmons on his blog, is “what system that works like Twitter could exist without a company behind it?”
Simmons then proceeds to break Twitter down to its essentials: “under the hood, following somebody is really just subscribing to a feed of their statuses. Posting is really just updating a feed of your own statuses. So you standardize on a feed format. RSS would work great, of course, and there’s a ton of RSS reading and writing code out there already.”
Instead of Twitter clients, what you’d really be building is a real-time RSS client. That’s not a far-fetched idea. Dave Winer, the forefather of blogging and creator of RSS, has been building one for years. (He’s also been telling everyone to build a distributed Twitter-like publishing system for years.)
Simmons doesn’t address it directly, but it’s worth noting that building such a system doesn’t preclude using Twitter. It’s not either/or, it can be both. In this scenario you’d write a post in a client like Tweetbot and Tweetbot could automatically send it Twitter and to your own feed. Start with both and then a migration away from Twitter would be smoother. Those that want to dump Twitter immediately could do so, but still keep posting to anyone with a client that supports the open structure. Then, if Twitter really does cut out third-party apps completely, the infrastructure necessary to support an open alternative is already up and running.
Simmons has more details for developers on his blog and in a follow-up post that delves more into the logistical complexities, but the basic message to developers is simple: Twitter’s changes means you need to find a better network for your clients to use.
The better network is the one that’s always been there — the web. The advantage for app developers feeling threatened by Twitter’s API changes is obvious. As Simmons writes, “there’s a practical reason to use the open web: your app can’t be shut down.”
The question is, if there were an open alternative would disgruntled Twitter users embrace it? The main argument against any alternative is the so-called network effect: Everyone I know is on Twitter; why would I go somewhere else? But not too long ago no one used Twitter and everyone used Myspace. Everyone used Friendster. Everyone use AOL. People change; networks move. A distributed version of Twitter sans Twitter might well be the web to Twitter’s AOL, but there’s one certainty: We’ll never know until we build it.