As an advisor to SocialToo, Jesse Stay, the developer of the service, and I trade a lot of e-mail... we also talk on the phone and exchange direct messages via Twitter on how to improve his service. Some of the ideas I've had already have made a small impact on the service, while other pieces will come much later. But last night, Jesse sounded an alarm that the service itself could be in jeopardy, thanks to proposed changes from Twitter's API team that would set limits which essentially cripple SocialToo's capability. And as much as I want to champion the immediacy of Twitter, the real-time aspects of the service, the community, and its outstanding search engine, this isn't the first time I've been left feeling cold about how the team has impacted its users or development community.Previous Discussion:If you have your head buried in RSS feeds and the tech Web, you've likely already seen the major issue - either from the SocialToo blog itself, or on sites like ReadWriteWeb, CNET and others, including Chris Charabaruk and TweetLiberty. Essentially, the limits are a hard number that aggressive services could easily surpass, assuming solid customer growth. And as developers like Jesse and others start to use the Twitter community and trends as their data set, they keep running into roadblocks. At first, Twitter was failing due to simple aspects of scale, but now, it seems as they make headlines for record traffic and involvement in world news, they are making headlines again for the wrong reasons - things that could be better massaged with improved tact and transparency.
Twitter's move, at its heart, looks to be one to protect themselves. As API Lead Alex Payne wrote yesterday, "This is essentially a preventative measure to ensure that no one API client, even a whitelisted account or IP, can consume an inordinate amount of our resoures." (sic)
But there didn't seem to be any options for services, even whitelisted ones like SocialToo, to get a work-around. There was not an option to pay to get increased access capabilities, or even tips on how to optimize code so that it takes less effort to achieve the same result. Twitter wants revenue, and the development team wants Twitter to succeed. So does everybody else, essentially. But my understanding is that Twitter has made it very difficult for some services to do the things users are asking for - including automatic following and unfollowing, because they aren't really that interested in providing such functionality. That doesn't sound promising for developers of SocialToo, Qwitter, FriendOrFollow and others. What other providers, such as FriendFeed and Facebook, offer in full, Twitter parcels out in bits and pieces, and seemingly expect the community to be grateful for it.
So now, Jesse and others are faced with a tough situation - is it even possible to optimize their code? Should they ditch Twitter as a development platform altogether because the company treats them like leeches instead of celebrating their efforts? Jesse asked in an e-mail, "Why develop for the Twitter platform any more if we know we can only grow to your limit?", adding one option for him may just be to exclude the most popular users outright to reduce stress on the system.
I'm not sensing a developer mutiny overnight. Twitter at this point has practically become a mainstay of most digerati's online experiences. Even if there are products that are better, Twitter has the momentum. Twitter has the growth and the buzz. But they are acting like they know it. Alex followed on to today's discussions, via Twitter of course, saying: "If people just asked us rather than making assumptions, there would be no story :)" But I'll be direct here - I saw Jesse's questions. He asks lots of questions and gets some answers. There is still a story. The story is that people who have made some very innovative and interesting products on a service with no revenue are very concerned about whether they can trust Twitter and if Twitter wants them to succeed - period.