Having some experience with the twitter API as a developer I know that as easy as it might sound to create a twitter client, there are quite a few things that make it quite a lengthy task. API limits, api downtimes and even wrong or inconsistent results can make developing a twitter client more time consuming than expected. It shifts attention to issues you have not considered before. It often takes away resources from usability engineering and the design process in general. But these steps are critical for creating something successful. Successes like the ones of  Tweetdeck and Seesmic Desktop are seldom.

The mentioned twitter clients for the desktop are really good, but not great.  They have gained more and more features over time, but not a lot of really big innovation has happened in this space. There’s still no Spam filtering, link collection or deep social graph analytics.

What can be done to foster innovation in that area? We have great desktop clients that cache our twitter data locally, but nothing really interesting is done with it. It’s like Outlook without Xobni.

Who will win the twitter desktop client war? I think it will the client that opens up to developers by offering a plugin architecture. Just like Firefox became incredibly useful overnight with the addition of plugins, that same approach will give developers a great advantage by not having to develop the basic client functionality over and over again. They can focus on great functionality without doing the plumbing. And the desktop client becomes more and more useful with every plugin, thus creating the next hotbed for innovation.

The next generation twitter client will be created by you and me.

Update 8.38pm GMT+1: Just about 4 hours after writing this post, I discovered that Seesmic for windows with plug in support (like in Firefox!) was released today. Crazy. Here’s the link.