On the Friday before the week of the Independence Day holiday in the United States, Twitter—again—reiterated to developers that they should not encroach on its efforts to standardize the experience for users of its popular microblogging service. Twitter’s group product manager Michael Sippey couldn’t have made it much clearer when he wrote of the “... importance of us providing the core Twitter consumption experience through a consistent set of products and tools. ... We’ve already begun to more thoroughly enforce our Developer Rules of the Road with partners, for example with branding, and in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used.” Developers who didn’t get the memo almost certainly got the message when Twitter pulled its cross-posting agreement with LinkedIn.
Third-party Twitter developers are not happy, but the message is clear: We’re going to squeeze every bit of value out of this for ourselves; you don’t matter one whit.
In 2010, Twitter bought the popular Tweetie iOS client and warned developers away from developing third-party apps for the microblogging service.
Last year, Twitter similarly flipped off third-party developers when it updated its developer terms and shut down several of third-party developer UberMedia’s apps. That’s the point at which Dave Winer wrote that Twitter moved past being a coral reef into gulag territory. Shortly later, Twitter began buying up Twitter client software apps by the bushelful, and that’s why the user experience of Twitter’s official clients are anything but consistent.
This should be dangerous territory for Twitter—the intertubes are littered with the carcases of services that betrayed users—but Twitter’s already gotten away with it. Twice. So, who knows.
To understand this, you have to remember that Twitter was built in 2006 by Jack Dorsey as an internal communications mechanism for Odeo, the podcast company. It was originally designed for short messages between members of a small group. Traction didn’t really come until the 2007 South by Southwest Interactive (SXSWi) conference when Twitter’s daily traffic tripled.
Dalton Caldwell attributes these shifts within the Twitter ecosystem to the realtime service connection API contingent of employees losing an internal battle to the advertising group who wanted to monetize the service through advertising. “If you are building an advertising/media business, it would then follow that you need to own all of the screen real-estate that users see,” writes Caldwell. “The next logical step would be to kill all 3rd-party clients, and lock down the data in the global firehose in order to control the ‘content.’”
Because the realtime service connection API contingent lost, it’s probably too late for Nova Spivak’s suggestion that Twitter monetize its API with two options of either embedding advertising in the API stream of freeloaders and a license fee for an ad-free API stream.
Anil Dash writes that both Caldwell and Spivak are wrong because no one wants a realtime cloud API except geeks and geeks no longer determine the future of Twitter. I have great respect for Dash, but I’m hoping he’s wrong here.
If you’re paying attention, Dave Winer succinctly articulates the situation in a tweet: “The mistake we all made with Twitter, me too, was to think a corporate API could act like an open protocol.”
Winer has been working on addressing corporate APIs and open protocols—using RSS and OPML—in publishing platforms for years. He’s getting close with a variety of apps that run inside his OPML Editor.
For me, for now, I’m spending a bit of time working with Winer’s stuff and with StatusNet.
Update: Saturday, 7 July 2012 9:18PM CDT: Dave Winer has updated his thinking on Twitter: “Twitter is a Corporate API.” Strongly recommended, especially if you’re a developer or publisher.