In a statement issued today by Twitter on its official developer mailing list, the company informed third-party developers that they should no longer attempt to build conventional Twitter client applications. In a move to increase the "consistency" of the user experience, Twitter wants more control over how its service is presented to users in all contexts.

The announcement is a major blow to the third-party application developers who played a key role in popularizing Twitter's service. More significantly, it demonstrates the vulnerability of building a business on top of a Web platform that is controlled by a single vendor. The situation highlights the importance of decentralization in building sustainable infrastructure for communication.

The message was posted by Ryan Sarver, of Twitter's platform team. He contends that over 90 percent of Twitter's audience is now using a client built by the company rather than a third-party offering such as TweetDeck or Seesmic. He also claims that the diversity of the application ecosystem and the differences in presentation between individual client applications is "confusing" for end users.

The message is that major third-party developers who make well-established client software and already have audiences will be able to continue supporting their users, but new developers should refrain from building their own client applications.

"We need to move to a less fragmented world, where every user can experience Twitter in a consistent way. This is already happening organically--the number and market share of consumer client apps that are not owned or operated by Twitter has been shrinking," wrote Sarver. "Developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no."

That's right, Twitter just told its third-party client application developer community that it is no longer wanted. Existing developers will face challenges going forward as Twitter takes back the platform. The company is adjusting the terms of service that govern its APIs in order to define stricter requirements for conforming with Twitter's expectations regarding how the service is presented.

The changes to the terms of service that were introduced today prevent third-party developers from displaying data from alternate services alongside data from Twitter's APIs. The intention is to block developers from presenting their own trending topics or follower recommendations in Twitter client applications. Sarver hints that more significant changes could come in the future, possibly including limits on what words applications use to describe features.

The tone of the terms of service has also broadly changed to reflect Twitter's complete abandonment of leniency or room for negotiation. Where before Twitter was willing to discuss its policies to an extent and make allowances for applications that have compelling reasons to need exclusions to the standing policies, the company is now laying down a zero tolerance policy. Applications that don't conform will be given the boot, and there is no room for exceptions.

During the recent user uprising over undesirable changes to Twitter's iOS client, many frustrated users found refuge in third-party client applications. When Twitter starts rolling out more intrusive revenue-generating changes to its software, it's likely that such changes will be accompanied by corresponding modifications to the terms of service that will force third-party developers to follow the company's lead.

The third-party developer community is livid and views Twitter's statement as a major step towards completely locking out competing client applications. The consensus, however, is that it was easy to see this coming. Last year, venture capitalist Fred Wilson warned third-party developers to avoid becoming "hole-fillers" in Twitter's garden, because the company would soon be taking over roles that had traditionally been filled by third-party developers.

A competitive collision between Twitter and third-party developers became almost inevitable when the company acquired Atebits, the startup behind the popular Tweetie client application. Twitter now has its own clients for iOS, Mac OS X, Android, Windows Phone 7, and Blackberry.

What seems to surprise third-party developers more than the new restrictions and changes to the terms of service is the brazenly dismissive tone that Twitter has assumed towards a group of developers who were once the service's strongest supporters. We discussed the change with Ed Finkler, the developer of an open source desktop and mobile Twitter client called Spaz.

"Twitter started as a very dev-friendly service, but as supporting those devs interfered with the ends of their investors—making money—they have become less and less welcoming. They are, of course, well within their rights to do all this. And it's not surprising. But it's disappointing all the same, especially to those of us who were there in the beginning," he told us. "I will continue to work on Spaz. That will not change. But I will not put any more effort into Twitter-specific features. It is, I believe, inevitable that Twitter will block 3rd party clients entirely at some point in the future or charge for API access."

Indeed, similar sentiments are being expressed by other third-party developers in response to the news. Although Sarver contends that there is still plenty of room along the edges for developers to build other kinds of vertical services on top of Twitter, the third-party developers who are reeling from today's announcement are concerned that other parts of the stack will be next on Twitter's hitlist.

"Twitter continues to make hostile and aggressive moves to alienate the third-party developers who helped make it the platform it is now. Today it's third party Twitter clients. Tomorrow it'll be URL shorteners and image/video hosts. Next it'll be analytics and ads and who knows what else," wrote Steve Streza, developer of Swearch and Todolicious, in response to Twitter's announcement.

Beyond Twitter itself, this situation reflects the uncertainty of building businesses on top of the social Web. The API-based business model--which puts companies completely at the mercy of a platform provider--comes with lots of risk, especially when network effects come with lock-in and make it difficult to simply rebuild on top of a competing service.