LOLZ Studios

The story of Twitter has been an impressive one. Over just a few short years, we have seen a tiny site based around a simple but ultimately brilliant idea grow into one of the biggest and most innovative startups on the Internet. Personally, I would say that much of the site’s meteoric growth could be attributed to its third-party developers, who work with Twitter’s great and expansive API to build applications, ranging from sensible ones like Bit.ly and TwitPic to the more inane ideas . And let’s not forget the ubiquitous Twitter clients for just about every platform you can think of: Windows, Mac OS X, iPhone, Blackberry and even Linux!

This week has been a big week for Twitter - it hosted its first ever conference, known as “Chirp” in San Francisco, CA. In last night’s keynote, we saw the launch of a brand new developer portal (which is looking great, by the way) and the announcement of a few interesting new features - namely the introduction of a streaming API for developers to allow for a better quality of service in desktop apps, and the upcoming ability to add any metadata you want to tweets created in your own apps, providing an unlimited number of possibilities for expansion of the Twitter platform. But I’m not here to talk about the brilliance of Twitter and its success, but rather how it is perhaps permanently ruining itself by driving a stake through the heart of its developer community, which in the end are probably the main reason why the site is as good as it is today.

I think, today, the main concern of Twitter developers is how the company behaves towards them on its platform. It waves amazing extensibility and freedom to coders in the form of its easy-to-use and open programming interface, but then takes it back by integrating the most popular features into its basic functions, thereby destroying the companies that originally created the feature. I feel that this issue of Twitter Inc. perhaps becoming “too big” has particularly come to a head in the last week, with Twitter’s purchase of Loren Brichter’s startup AteBits, developer of Tweetie, one of the most popular Twitter clients for Mac and iPhone. Twitter’s intention is to make these apps free, instead of using the current paid model - but how is this fair to Twitter’s client developers who have spent time and ultimately money on building their own clients, only to have their applications knocked out of the ring by a first-party solution? And of course, Tweetie is by no means the only example of this - Twitter has also just announced its intention to release its own URL shortening service, competing directly against Bit.ly, one of its long standing partners which up to this point has been the official URL shortener of the site.

None of these changes have directly effected anything I have made, but it is still a worry to me and the thousands of other Twitter API users across the world. Once you’ve developed your application, how do you know that there will not be a first party version once you’ve gained some popularity? Of course, the answer to that question is, you don’t.  

Some people try to counteract claims like these by saying that there was already competition and just the fact that Twitter owns it does not make a difference. But I disagree - how long will it be before we see apps like Tweetie gain extra “privileges”, like an increased rate limit or early access to new features? And if an application is directly integrated into the Twitter.com UI (which is by far the most popular way to tweet, even today), it will obviously gain an unfair advantage, particularly with new users. Obviously, an application branded as being “official” will also gain an advantage compared to one made by any other company.

I have also noticed some changes in the flexibility of the Twitter developer platform. Now the new Developer site has launched, Twitter is being much more vocal in its plans to depreciate the basic authentication options for the API. I agree that this is desirable in terms of security - after all, it is obviously not a good thing to have to give your account’s username and password to a third party service in order to use it. But, the problem is, in many cases using your username and password to authenticate may be desirable: I use the more secure OAuth authentication service for my web projects, but if I want to make an internal application or just play from the command line, it is far more convenient to just tap in my username and password. Forcing users to use OAuth creates a sizable obstacle to any users who are just getting started - although there are very good libraries available for just about every programming language (like EpiTwitter in PHP, my personal choice), the whole idea of OAuth is confusing (for me, at least) and makes it far slower to get started with developing, as you have to get to grips with what OAuth is, create your application on the Twitter website, and then go through the process of making a script to perform the authentication with Twitter and store the OAuth tokens. For this reason, I think Twitter’s decision to abolish the standard authentication is a mistake, and possibly a serious one for the future of the platform.

A decline in Twitter’s flexibility is also visible in Twitter’s new display guidelines. Twitter has done a great thing for its ease of extensibility with the new @Anywhere tool, which allows any website to include Twitter features very easily, but with these it has introduced a whole host of guidelines for how tweets must be displayed and how Twitter’s brand should be represented. Twitter is now expecting developers to comply with a whole host of requirements, from the sensible (having to include some sort of attribution to Twitter for the content) to the slightly absurd (having to display users’ avatars on the left, not the right).

Part of the problem is that it appears that Twitter does not understand how developers are likely to react to these unwelcome changes. It gives the image of expanding its platform, which is by all means a good thing, but what good is a platform on which few developers will build, for fear of their idea being essentially stolen by the powers that be? I don’t claim to not appreciate Twitter’s predicament - it wants to provide the best basic service it can to its user base. But a trade off has to be made in order to appease the developers on which it so heavily relies.

Of course, another reason for trying to build more information directly into the Twitter system is one of money. Much of the company’s potential revenue lies in selling data to third-parties, which is, for example, likely to be the main motivation of Twitter’s recent addition of built in location services on its main website. People views and thoughts is one thing for targeted advertising, but how much more useful is that if the advertiser can also deduce where that person is?

In conclusion, Twitter faces a serious problem, which I can’t see being solved any time soon. On one hand, it should be working with, rather than against the developers who have worked hard and contributed to its success, but on the other hand, without a revenue stream, there will be no Twitter in a few years time! Perhaps the solution for developers is to build Twitter into their existing projects as an additional feature, rather than relying on it totally for their business. The Twitter OAuth API provides the perfect solution to make this a reality for many website.