Some thoughts about Twitter plugins

Twitter has given the Web a great gift. Sure it has its detractors just as it has its fanbois but there is no denying that Twitter has become an integral part of our web use in large part due to the rich third party ecosphere that the openness of the Twitter platform provides.

Blog posts after blog posts are written almost monthly about the numbers of Twitter users and how the service is stagnating, losing or gaining ground. The problem is that the whole pageview model is broken and Twitter is the shining example of that. This is because the large majority of users are using at least one if not more of the many clients that are available for Twitter.

Just as Twitter has grown so has the community of developers around the service and it is to those developers I want to spend a few minutes talking with.

You guys are building some great apps for Twitter users and every version of your apps bring something new to the table as Twitter opens up more possibilities through their API and now you are talking about adding plugin capabilities.

I first ran across this using MahTweets and now Seesmic has announced that they are going to be including a plugin architecture to the next release. While this is a great idea that will allow for even more abilities to be added to Twitter clients for the benefit of us the users I would ask you all to stop for a moment and think about this whole plugin thing and about us the users.

There is no doubt that the idea of plugins – for anything – is a bonus that allows for easy extensibility of a core application. It is also a great way to build a community around one’s product but in some ways the idea has also been extremely limiting for the user. After all as good as plugins might be they are typically locked down to one specific application which limits its use in other cases where the plugin could also be useful for the user.

The two perfect examples of this are browser plugins and smartphone apps.

In the case of our browsers plugins are clearly delineated by the browser they are coded to work with. Instead of having a plugin that can work regardless of which browser you may be using at the moment we have to hunt up; if even available, our favorite plugin for each of the browsers we use and install each separately. The newly announced initiative from Mozilla Labs called Contacts which is suppose to let us consolidate all our contacts in one area using the Portable Contacts format is a good example of a great idea being limited.

It is understandable that Mozilla is tying the idea in with their Firefox browser but what about the rest of us that don’t want to use Firefox. It is ideas like this that should be universally available regardless of browser or platform with a single install, which of course would take the operating system into account.

This is the same problem that plagues application developers for the smartphone. Instead of being able to pay once, or get for free, and use on any smartphone platform these apps are platform dependent. Again this is understandable from the platform provider but is totally aggravating to the end user.

So what does all this have to do with Twitter and plugins for all those third party clients out there?

Well first let’s look to one of the founding principals of Twitter. From the very beginning Twitter has made a large portion of the data flowing through its pipes freely, and easily available through an API that can be accessed by anyone on any platform. Whether you use TweetDeck, Sobees, MahTweets, Seesmic, Tweetie, or…. well.. pick your favorite they all access and use the same stream of data.

This is a win for the user, Twitter and all those clients.

Now we come to this idea of plugins for Twitter clients and why I would ask client developers to stop for one minute before they start going nuts on adding a plugin architecture.

Just as Twitter has made accessing their data drop dead simple so any developer can create their vision of the best Twitter client I would love to see those developers come together and create a common plugin architecture or plugin API. It would be a common plugin platform that, regardless of the client we are using we can use the same plugins without having to waste our time installing some must-have plugin every time we switch a client or even switch platforms.

This would also be a bonus for the plugin developers as they would be able to create killer plugins and not have to worry about whether they need to create separate version for all the major clients.

In the end though we would all be winners.

Comments