I think the opportunity has passed for the Twitter API to become a lingua franca for the real-time web. WordPress.com, Tumblr, Typepad, SocialCast, and Status.net all added support for the API in a way to make it as easy as possible for Twitter client developers — all they had to do was change the endpoint. The clients would then become a hub for users across different services, and had the ability to flourish regardless of the direction of the service they originally built on.
However because of perceived lack of market or a rush trying to keep up with each other and new features in Twitter’s API, like geo-location, we’re now close to half a year later and support for alternative endpoints in the major clients is haphazard at best. One of examples we all used to point to, Tweetie, is now owned by Twitter Inc. and doesn’t have much motivation to support other services in the future. Neither do the other official clients they’re rolling out. (Twitter.com/downloads is now a 404 page.)
For the record I completely support Twitter creating or buying official clients for every platform, including desktops. It’s what I would do in their position. However the third-party client developers that contributed immeasurably to Twitter’s success thus far are now in the awkward position of no longer being useful to their parent. It makes no sense for Twitter to have its user or signup experience mediated by a third party. None of the third-party clients have innovated enough in the user experience (for the most part they do not look or work significantly different from when they launched) or in cross-service support and flow.
If any of the clients had added seamless third-party API support when the opportunity first arose we’d all be pointing to them and promoting them. Now we’re more in a situation where, like Twitter, it makes more sense to build and promote our own because our users are demanding a multi-modal experience.
I would love an all-in-one posting application, currently I just use Tweetie and the WordPress App.
I really wish Twitter had just written a VERY basic reference Twitter client and allowed the developer community to build extra functionality and release competing apps. Tweetie was one of the best and most full featured and having it as the official client may cause the Twitter app ecosystem to grow stale as developers now have to work exponentially harder to compete.
Twitter did do exactly this. The twitter.com is their reference client but the desktop & mobile clients couldn’t keep up with the innovation on the web so it looks like they’ve taken matters into their own hands.
Twitter has a great API, and right now third party developers re-evaluating their business models have a great opportunity to leverage their existing work into all kinds of cool new stuff by supporting other endpoints. I hope more of them will recognize this in what’s turning out to be a real watershed time for the changing landscape of the social web.
I’m agree with your look at the ecosystem for Twitter posting clients, but don’t agree with your conclusion. (As you might expect, based on my advocacy of the Twitter API as a standard.)
The mistake I think you’re making here is in focusing solely on the posting/reading applications as the primary type of “twitter app”. They’re actually the least interesting part, from my standpoint. If you look at something like One Forty, with a directory of all kinds of Twitter apps, the ones that are for simply reading or writing tweets are among the least interesting, and most appropriate for commoditization. I don’t even think it’s inconceivable that Twitter will add third-party API endpoint support to its own first-party clients.
More importantly, the various analytics tools, games, media add-ons, and infinite other apps that are built around the APIs would be a valuable set of capabilities for users on any platform. If the ecosystem of Twitter application developers feels concern or uncertainty about the future of their work because of Twitter, Inc.’s recent moves, I’d suggest that knowing they could reach WordPress, Tumblr, TypePad ( which also supports the Twitter API) and StatusNet users would definitely help them feel less vulnerable.
That being said, posts like this are usually used to telegraph the fact that you’ve already made the decision to create your own API, which of course is your prerogative. In that case, I’d look at the simple JSON APIs that are out there for Flickr, TypePad, TwitPic, Tumblr and others and see if you can’t just go for the second-movers’ advantage instead of starting from scratch.
“already made the decision to create your own API”
I don’t think we could handle another API! Already support XML-RPC, Atom API, Twitter, Jabber, email…
More to telegraph the fact that it’s less interesting to keep up the Twitter API clone if no one is going to support it properly.
I think reading and writing is still pretty interesting, and is the base. If even the reading/writing apps don’t have multiple endpoint support, I can’t imagine the complex analytics and games services are going to bother.
Thanks for reminding me about Typepad support for Twitter API, I’ll add them to the post.
Matt, I feel there is need for improvement of existing wordpress APIs, while also providing new read-only type APIs. For example, in case of Tweets, you can get lot of metadata about the creator and the Tweet itself from the Twitter api. Like – http://twitter.com/statuses/show/13377986068.xml. As compared to that, a WordPress Post feed, like – https://ma.tt/2010/05/twitter-api/feed/, is mainly focused on comments. It would be great if this feed also provides information including author, publish date, update date, geo, tags, categories… Also, there are no p2 theme specific APIs or feeds right now. Not sure even if there are any P2 specific feeds. Also, how about a Search API, or an API similar to Twitter Firehose statuses/Links
Add ?withoutcomments=1 to that feed URL and you get a single-item RSS feed about that post.
To get a search feed just ad ?s=term to the end of any feed.
“I don’t even think it’s inconceivable that Twitter will add third-party API endpoint support to its own first-party clients.”
If that happens it’d be killer, and signal to the whole community a genuine commitment to openness.
How do you feel about OStatus and ActivityStreams generally? Once we solidify the JSON representation, it seems like we’ll be well-positioned to provide a fairly stable, derivative of current common behaviors and practices.
I think we’ve come a long way in the last 3 months actually — it’s starting to really come together!
In general I like things that start with “O.” Beau seems excited about the implications for Gravatar profiles. Beyond that, I am still twice burned on specifications leading innovation — I’m more confident investing in something led by a consumer killer app.
What difference does it make to start things with “O”?
In any case, fair point — perhaps Buzz’s support for ActivityStreams will help usher in some new killer apps by making a new kind of data available to work with.
Curious, then, how you feel about the Open Graph Protocol?
Just to bring the pepper to the conversation;
All the content, comment, opine and conversation which is created around publishers content (Buzzing and Tweeting links) on these silos is as useful (monetizeable, keeps readers attracted to the brand/the publisher) as cow dung for farmers.
Farmers use it to dung their fields, but additionally they need to buy pesticides and fertilizers to grow more and better stuff.
Ie Twitter asking Google and Microsoft to go to the till, the firehose is not free.
If the NYTimes had access to the Firehose of Buzz, FB, Twitter, I could think that they would do things differently on their nytimes.com homepage. More algorithm. they had more meta about the users interest, past tweets, lists, follows. Better targeted ads, better recommended articles.
That is where FB Open Graph comes into play. And a play with privacy.
Reading through the lines, your last paragraph inclines that you are currently working on an Android/iPhone OS application dedicated for WordPress?! Or planning to, or about to release.
Reads like Fred Wilson and his ‘filling holes’ Twitter post days before Chirp.
“If any of the clients had added seamless third-party API support when the opportunity first arose we’d all be pointing to them and promoting them.”
Like the big ones (Seesmic, Tweetdeck) on Android/iPhone OS. Seesmic bought ping.fm, ping.fm does support WordPress. But there is not a lot of diversity, buzz out there – you are right.
Interesting post Matt!
Regarding Twitter we’re in limbo now, I think, right in between ‘de facto’ and ‘de jure’. Smart innovators and adopters added client-support for Twitter’s default and changing behaviour, expecting to get some spin-off out of that. The continuation of that behaviour is somewhat linear to the actual generation of spin-off as it was expected, I think
What’s wrong with the API’s though? Is it the semantics? The syntax? Is it the form, like XML versus JSON? Is it the the lack of (mutual?) support? Is it the lack of business demand, or supply? Or is it financial?
What do you expect of a lingua franca anyway? What is its goal, what is its form(s)? I speak a few human linguas francas myself, like Latin, French, English and Spanish, so maybe I can help out?
I think that should be “linguas franca”,
(at least in English).