Thanks for finally making this clear, Ryan. I've been critical of the way Twitter was handling whitelisting for months now. Hiding and ignoring are not good ways to build a developer community. While it would be great to have the possibility of whitelisting, it is much worse to offer that promise to clients and investors and then not be able to deliver it. Now nobody can make plans based on whitelisting. As Edward pointed out in his response, the really devastating thing would be for Twitter to still offer whitelisting on the side to a chosen few. If this is supposed to be a level playing field, please make sure it really is. Breaking that promise would be the worst form of lying.
This doesn't have to eliminate apps. It just forces them to change focus. As you say, as long as you are doing things for users, instead of for investors, there is still a huge field to play in, and to make money. This week I have gotten multiple requests to work on projects that tweet for users, and tweet to accounts that are read by users. The key is that this is done for actual Twitter accounts. I see no problem building a solid revenue stream on this type of consulting. I also want to build sites that can be used by many thousands of users, and then monetize them by selling mobile apps, or advertising. I don't see how this change would block that. What is now blocked is the idea of following every user, and every follower of that user, without any actual users asking to do so. Trying to suck in all data and make money on the resulting analysis is not going to happen. Was there ever any money in that anyway? Now the next step in opening up this marketplace is to create multiple resellers of Twitter API data, and let them compete on price. Giving Gnip a monopoly over this market makes no sense. Twitter's biggest problem is the huge volume of requests. By blocking whitelisting you are forcing some developers to cheat by creating multiple accounts and distributing their requests across them. That can never be stopped. What you have to do is make it inefficient, by letting multiple resellers complete and drive the price of Twitter data down. Then the strongest reseller will take the load off of you and offer enough value added that developers will be willing to pay for data. That will never happen when only one reseller sets the price. You are riding a tiger. Good luck, and try to stay open and honest. This is a good step on that path. I've been watching software companies try to manage their developer communities for 31 years. As long as you tell the truth, you will succeed. On Thu, Feb 10, 2011 at 4:43 PM, Ryan Sarver <rsar...@twitter.com> wrote: > Beginning today, Twitter will no longer grant whitelisting requests. > We will continue to allow whitelisting privileges for previously > approved applications; however any unanswered requests recently > submitted to Twitter will not be granted whitelist access. > > Twitter whitelisting was originally created as a way to allow > developers to request large amounts of data through the REST API. It > provided developers with an increase from 150 to 20,000 requests per > hour, at a time when the API had few bulk request options and the > Streaming API was not yet available. > > Since then, we've added new, more efficient tools for developers, > including lookups, ID lists, authentication and the Streaming API. > Instead of whitelisting, developers can use these tools to create > applications and integrate with the Twitter platform. > > As always, we are committed to fostering an ecosystem that delivers > value to Twitter users. Access to Twitter APIs scales as an > application grows its userbase. With authentication, an application > can make 350 GET requests on a user’s behalf every hour. This means > that for every user of your service, you can request their timelines, > followers, friends, lists and saved searches up to 350 times per hour. > Actions such as Tweeting, Favoriting, Retweeting and Following do not > count towards this 350 limit. Using authentication on every request is > recommended, so that you are not affected by other developers who > share an IP address with you. > > We also want to acknowledge that there are going to be some things > that developers want to do that just aren’t supported by the platform. > Rather than granting additional privileges to accommodate those > requests, we encourage developers to focus on what's possible within > the rich variety of integration options already provided. Developers > interested in elevated access to the Twitter stream for the purpose of > research or analytics can contact our partner Gnip for more > information. > > As always, we are here to answer questions, and help you build > applications and services that offer value to users. > > Ryan > > -- > Ryan Sarver > @rsarver > > -- > Twitter developer documentation and resources: http://dev.twitter.com/doc > API updates via Twitter: http://twitter.com/twitterapi > Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list > Change your membership to this group: > http://groups.google.com/group/twitter-development-talk > -- Adam Green Twitter API Consultant and Trainer http://140dev.com @140dev -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
