Why Twitter clients don’t matter

Posted in Conversations, Tagged with clients, twitter

Since creating TweetSharp, I’ve had the opportunity to speak with a lot of folks who are using it to build their Twitter projects, which is great to hear. Most developers feel that a) the current state of the union for Twitter clients like Seesmic Desktop and Twhirl, TweetDeck and hootsuite, blu and Witty, just doesn’t do “all of the things I’d want a Twitter client to do”. And this is fair criticism, since client developers can’t possibly anticipate every use for Twitter, and new uses are emerging all the time.

The most common use for TweetSharp has been to accelerate the development of Twitter clients, which makes sense considering that is exactly why it was written in the first place. It is the API running the show behind the scenes of our own client. After working hard over the last while on our next-generation Twitter client, and watching the community conversations about taking things to the next level, we’ve realized: Twitter clients don’t matter, applications do. Here’s why:

• Too many choices. I have a pet prediction that there will be around thirty choices of Twitter client around the summer of 2009. I know of several development teams working under a veil on their version of client revolution, myself and @jdiller included, that plan to launch this summer. This is great for users, the more options the better, but usually when faced with overwhelming alternatives, people stick with the default. That means more TweetDeck users, and more developers with superior offerings left scratching their heads.

• Lack of diversity. The next evolution of Twitter clients will ultimately need to make journeys into extensibility; it just makes sense. Features like groups that persist across devices, interchanging multi-column and condensed views, slick UX, offline support, are not innovations when every developer who builds a client knows those features are necessary and are part and parcel of good software: this is the minimum bar. That means having a client that can load plugins to extend features, and possibly opening up that plugin model for others to build on top of your client, are going to be part of just about every competitive Twitter client going. TweetDeck will bring these features in if they aren’t working on them already. That means more TweetDeck users, and more developers with superior offerings left scratching their heads.
• The sunset of “features-as-applications” . Once the vast host of Twitter clients converge on the same basic set of features and offer a decent extensibility model, the game will change to swallowing up all of the applications that have managed to attract a following simply because they fulfill one missing feature of Twitter’s default offering. Want to know who’s stopped following you? That’s Qwitter. Want to broadcast tweets at certain times to pre-defined groups? That’s TweetLater. And the list goes on, but all of these applications are not true applications, they’re just features. Features are not a good reason to build a business. The Twitter client army will devour these features as either native functions of the client itself, or bring them in piecemeal as plugins.

What’s left are applications in the true sense of the word: unique software that solves a particular need, whether broad or niche. This category is as wide open as innovation itself. You’ve always had the option of doing something remarkable.

Want to know how to get users to switch from TweetDeck to your client? Build an application worth switching clients for, then offer it exclusively from within yours. All things being equal–and they will be sooner than you think–nobody is loyal to their Twitter client.