Twitter are gambling that they are now powerful enough to say "No more 3rd party clients", and thus start streaming ads down peoples throats (oh, sorry - "Richer stories" is apparently the nuspeak). I'm not sure they're yet in a position to dictate this, especially given how bad their own clients are compared to some other options.
The interesting thing about Twitter compared to e.g. Facebook is that the social graph is very weak. I (and in anecdata, many people I know) use it to follow some "big names", and a splattering of smaller names, for broadcast information. I occasionally send something out, but it's not a strong set of connections. The network effect is thus minimal; migrating over to app.net would be easy, as I'm not that bothered that I have exactly the same followers/followees. When the pain of the service outweighs it's smallish value, I'll just jump ship.
Even more people out there are just passive followers of celebrity names. Facebook or similar could launch a "Flitter" that did everything they wanted, and get a mass migration pretty easily - once people get annoyed enough to start looking around. If Twitter continue on this path, that threshold will be reached much sooner than I originally expected.
If the problem is that they can't figure out how to monetize third party apps, the answer is staring them right in the face.
So, Twitter is already going to dictate what the tweet view looks like. In-stream ads won't be much more than tweets. So why not stipulate that an app MUST show in-stream ads in a given format? If the app wishes to not show ads or to use twitter for more of an "infrastructure-like" purpose, then there should be some kind of use-fee-based pricing model on the API side. Sure, people might bitch about the high API costs, but it's better than nothing.
Or maybe that was their plan all along: throw out these API changes threatening to cut everyone completely off, then eventually "concede" with new ad-supported and use-fee API rules and have everyone applaud them for "listening to their customers".
You'll have to forgive me for being more cynical than normal... but with this twitter stuff lately it just seems like we've all entered into the Twilight Zone of Suck.
> If the app wishes to not show ads or to use twitter for more of an "infrastructure-like" purpose, then there should be some kind of use-fee-based pricing model on the API side.
No need for this complexity. They could just revoke API access for apps that don't show ads per their guidelines. It'd be easy to catch any Twitter client with a significant user base that isn't showing ads properly.
At the end of the day though solutions like this just aren't realistic. If Twitter's going to show ads and other content like cards in their stream, advertisers have to have confidence that the content and presentation will be preserved. The only way to truly do this effectively is to control how your product is presented in all cases.
The problem isn't that Twitter's making these changes. The problem is that Twitter's only getting around to doing this now, years after a vibrant ecosystem of third-party clients has been well established. No one complains that there isn't a rich market for third-party Facebook clients, even though the Facebook app historically has been pretty substandard. Facebook, wisely, never relinquished control over their platform.
Twitter, as ever, is cleaning up for previous incompetence, trying to clean up a mess that never should have existed. How could they not have assigned one or two people to build an iPhone client the minute the iPhone SDK was announced in 2008? How blind do you have to be to not anticipate that mobile will be huge for Twitter, a service originally engineered around being used over SMS?
Watching Twitter bungle issue after issue over the years gives the distinct impression that Twitter is successful in spite of their executive management, not because of it.
> The problem is that solutions like this aren't realistic. If Twitter's going to show ads and other content like cards in their stream, advertisers have to have confidence that the content and presentation will be preserved. The only way to truly do this effectively is to control how your product is presented in all cases.
Thank you. It amazes me how people miss this. Look at it from the perspective of Twitter's customers (advertisers). Would you buy an ad without seeing exactly what it looks like, or without knowing with certainty that what they show you is what winds up in front of the users eyeballs? Having worked in advertising, companies pay attention to every last detail of an ad piece. This is the exact reason why Twitter has gone this way. That have to sell themselves to companies as trustworthy partner.
"Facebook, wisely, never relinquished control over their platform."
What did Facebook do differently? Third-party Facebook clients have been possible for quite some time, perhaps from the initial launching of their API.
I've tried various Facebook iPad apps and they all sucked. I think it's simply that Facebook has so many features and changes at such a rapid rate that it becomes unfeasible to write an app for it. Compare that to the wealth of Twitter- and RSS clients and weather apps. They're all gorgeous front ends around conceptually simple data.
I think it could work. The set of users who would pay is a completely different demographic than those who are following Justin Bieber. You're only devaluing the market for the adverts that would appeal to everyone.
"Twitter are gambling that they are now powerful enough to say "No more 3rd party clients"
Isn't it more: No more free data for 3rd party clients? (past a certain amount) Companies can still buy unlimited realtime data through twitter's monitization child DataSift. Meaning the death of free 3rd party apps. Maybe now that they have to charge a good chunk we will get better 3rd party apps?
Not certain about DataSift, but we used Gnip and part of the terms was you couldn't display tweets to your users directly off the firehose. I'd imagine DataSift has a similar restriction.
Besides that; neither give you access to private tweets or DMs, so you pretty much have to use the API for a client of any worth.
I (and in anecdata, many people I know) use it to follow some "big names", and a splattering of smaller names, for broadcast information.
Why is this a negative? To a first approximation, the "big names" you follow are an indication of your interests, and advertisers are very comfortable with broadcast media.
Following anyone also indicates a degree of commitment that simply hitting a "Like" button does not: You're willing to see everything that person/business Tweets.
A possible solution might be, since they are selling the application and not providing a service, is for users of the software to create their own application tokens and putting them into a new settings panel. There's no loss in sales, it does require an extra couple of steps for a user to get going but putting something like this in the advanced section or releasing it with just the Alpha might be very good solution.
I imagine Twitter's reaction to a major client doing such a thing would be less than favorable to developers (no more free API keys, if I had to guess)
I, for one, am very much looking forward to the eventual release of an 'AppBot' client, or whatever they end up calling it.
I may sound like a broken record, but I am incredibly disappointed in Twitter's behavior, especially given the great disparity in the feature sets of TweetBot and the official Twitter iOS client. (and don't get me started on the state of Twitter clients for Android...)
The future of unofficial Twitter clients might just be fully open-source code. Twitter can't stop every determined individual from creating their own application if the code is out there publicly. And with Twitter possibly cutting people off I wouldn't be surprised to see some clients become open source as they hit their cap. The question simply becomes how high the bar becomes for building your own personal Twitter application.
Actually, that would be a rather scary end-game for Twitter: completely losing control of their delivery platform.
If they went that route, they would be limited to 100,000 users. Tapbots likely had more users than that when the new API guidelines were announced, which means that they can have two times their current userbase, a (potentially) significantly higher number, if they keep the same key and secret as for the alpha.
So they have a "limited" beta with the first 10k new test users for each release getting to test it (and once in, you are always in). That would give them 10 testing updates before they hit their cap and a lot of useful data.
The last TapBots blog post, written a week and a half ago, had the title "Don't Panic" and characterizing the response as "fear, uncertainty, and doubt".
I think this vindicates most of the people who raised a big stink about the API policy changes back then.
Edit: They're also planning to create a Twitter-compatible API, so a vendor like Tapbots could simply change the endpoint in their code and support rstat.us as well. https://github.com/hotsh/rstat.us/issues/562
There is a point where third party clients are going to have to demonstrate that they are not required to go through Twitter to get access to it. Just as third-party IM clients long thrived without official access (and in the face of attempts to block them), and are now commonplace and tolerated, Twitter clients can (probably legally) switch to an API key borrowed from Twitter and be no worse off. Even though Twitter's actions aren't catastrophic for third party clients yet, the fact that nobody has used this approach is putting Twitter in a stronger position than they deserve.
Too bad they don't let a developer just kill an "app" and all its associated tokens. So Tweetbot could have a "Tweetbot Mac Alpha" app and then when they were done with the alpha, they could reclaim all those tokens.
While not ideal, they could register a new Twitter app for the released, for sale version of Tweetbot. Everyone would have to reconnect to that app (just as they originally had to do on the beta), but it should get around the issue as the new app would have zero used tokens.
Is that allowed? I figured all the TapBots apps were tied together somehow within Twitter (like separate apps on the same account) and Twitter would enforce that on new apps (since the limits would be meaningless otherwise).
> We’ve been working with Twitter over the last few days to try to work around this limit for the duration of the beta but have been unable to come up with a solution that was acceptable to them.
That tells me that they've already tried the obvious stuff people are suggesting in this thread and Twitter simply won't allow them.
Because they're not a blogging company, they're a software company. I'm betting they aren't too concerned with tweaking Wordpress performance as they are with building the things that actually make them money.
The interesting thing about Twitter compared to e.g. Facebook is that the social graph is very weak. I (and in anecdata, many people I know) use it to follow some "big names", and a splattering of smaller names, for broadcast information. I occasionally send something out, but it's not a strong set of connections. The network effect is thus minimal; migrating over to app.net would be easy, as I'm not that bothered that I have exactly the same followers/followees. When the pain of the service outweighs it's smallish value, I'll just jump ship.
Even more people out there are just passive followers of celebrity names. Facebook or similar could launch a "Flitter" that did everything they wanted, and get a mass migration pretty easily - once people get annoyed enough to start looking around. If Twitter continue on this path, that threshold will be reached much sooner than I originally expected.