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.