Yesterday, Twitter announced a change in the Terms of Service for API use and pretty much told developers that they shouldn’t be building Twitter clients. The reasoning given for this was that with so many users of the service, different clients offer different ways of interacting and could therefore confuse users. (Won’t somebody think of the children!)

One of the things I really admired about Twitter was that it was built as a true web service. Twitter isn’t a website, it’s a service into which you can place tweets and out of which you can retrieve tweets. As Tom would put it, it was native to a web of data – and a perfect example of a true service and not simply a website with an API bolted on.

To get users started and support light use, twitter.com sported a simple web client for accessing the service, which was perfectly adequate, if basic. Any serious user of the service could use one of the many Twitter clients to interact with the service via its API. It worked well because Twitter could concentrate on the core service (which, due to its popularity and growth has been an enormous undertaking in itself) and let third parties focus their efforts on building great client software. It was absolutely beautiful, and I still consider this as a template for how web services should be built.

Putting to one side the fact that Twitter is not a distributed service, this was in most other respects the way many other internet technologies have become so successful. Any web browser that can speak HTTP can connect to a web server to access a website. Any email client that knows POP3 and SMTP can connect to an email server and start enabling the user to send and retrieve emails. More advanced users might choose an email client that uses IMAP. Your email server doesn’t need to care about the user experience offered by the client software. It doesn’t care if the client is a GUI app, a command line script or even some other sort of server. And so it is with Twitter clients and the service itself. This allows for enormous flexibility, opportunities for developers, and fantastic user choice.

That’s why I did think it was odd when Twitter bought up the company behind the Tweetie client for OS X and iOS, and then channelled considerable effort into a new version of their default web client at twitter.com. I had put the Tweetie acquisition down to acquiring a talented developer, and I guess it does make sense to have the default Twitter experience on the site to be as good as you can make it. But the effort did feel misplaced.

Now it has become clear that Twitter wishes to own the entire user experience by having everyone using an official client, in a move akin to CompuServe requiring customers to use their official email client. (Remember them?) Or a website only working in Internet Explorer. (Remember those, also?)

I’m not in a position to predict what this means for Twitter as a company, for the popularity of the service, or anything of that nature. I suspect it will merely annoy a lot of the early adopters (who are an absolutely insignificant number of users), annoy a lot of developers, but we’ll all carry on using Twitter regardless. However, I do think it’s a massive shame for the industry as a whole. The perfect example of a company who understood how to be native to a web of data has gone. And gone in a way which suggests the model has somehow failed. But the model hadn’t failed at all. It was flourishing.

I can only presume that due to commercial requirements the official clients will be introducing features (such as ads) that users won’t necessarily like. Any move of that nature would be undermined by users having a viable choice of alternatives to switch to. Which would make sense, and is perfectly understandable. Twitter is a business. It’s just a shame they had to conduct the changes in such a way, and try and pin the change on a technical approach which was working magnificently.