Twitter’s Brett Seville—the lead UX guy for the fast-growing social media company—recently hinted that Twitter Labs is in the works. Like Google Labs, this would be playground for developers with access to platform engineers at a level beyond just use of their open API.
The continued formalization of Twitter’s relationship with their extended developer community is wonderful. The company’s success was built in large part to the way they share access to data, and 2009 has been characterized by increased focus on the platform. The explosion of third-party applications has increased from under 2,000 to over 28,000 so far this year. Most of that jump in activity has come since the start of the summer. It has spawned a company (oneforty) and several databases trying to keep tabs on these new tools.
On September 30, Twitter announced the impending creation of a new internal feature: Lists. Nick Kallen is going to lead this project, which will include API access to the creation, editing, changes and timeline for a given list. Although there were some complaints from the developer community about a lack of advance notice, the third-party applications most affected by Twitter Lists were excited about how this addition can help their own projects. This comes after formal support of retweeting and geolocation were announced in August.
If there is any cause for concern in this news it may be in a feature creep that moves Twitter further away from simple. Those 28,000 third-party applications are buoying niche communities and augmenting the kinds of things Twitter can do. To have features added to the Twitter engine itself runs some risk of adding complexity that changes how the service is both perceived and used. Geolocation, for example, will certainly strengthen local user communities (a great thing) but is problematic for a number of reasons. We are nearing the final quarter of 2009 without a clear idea of how the company plans to make money, so it will be interesting to see how closely tied these changes are to future revenue. Once that shoe drops, community reaction to these additions will certainly change.
As I wrote in my book six months ago:
It is a credit to Twitter that it has resisted such changes. Making the service less simple would also make it less versatile. The void of unanswered user requests for functionality is filled by an ecosystem of third-party developers. The incentive for the innovation and resources these developers bring to the Twitter community would be critically lowered if the main service tried to do too much. A simple Twitter is better not only for the users trying to post their status updates, but also for the third-party applications trying to find their niches.
I think this insight is still valid. After the dust settles on a stable version of the API and the company business model, simple must remain a touchstone for Twitter.