> There was a time around 2010 when building a Twitter API client was the standard demo for a new UI framework — the data model was simple enough that a basic client was the next step up from "Hello world" complexity.
It's fascinating the Twitter we have today and the Twitter from that era are even considered the same app. I wrote a simple Twitter client in Cocoa and Python and even NodeJS. It was such a simple way to get a working, functional, usable demo going that you could immediately show to friends.
Then they realized it's impossible to make money advertising this way and shut it down.
> I can see the value of APIs for a growing company that is trying to establish itself, but there must be a line somewhere. I suspect a large amount of API support over the last decade has been driven by brand development and recruiting.
It brought INSANE value to Twitter in it's early days.
The API allowed a client to be written for every platform around by domain experts way before the Twitter team could get to them. They got Apple to integrate it natively on iOS 5. That's right, the OS had built-in support for Twitter. You didn't need to install an app.
It's one of the things that cemented Twitter's presence in the social media's landscape.
>With the public API before it was heavily locked down I mainly used it in third party Twitter clients to avoid seeing the (revenue generating) ads in the official Twitter apps - I know many others who did the same. An open, freely usable Twitter API can actively hurt revenues at a time when Twitter desperately needed to demonstrate ability to generate profits.
I wonder if they ever investigated just making API access paid, not free? Users were paying for 3rd party clients making use of the API just because they liked them so much better already, so clearly there was some money in it. And it seems like the Venn diagram of "using client to avoid seeing ads" and "already running, or soon would run, adblock in the browser" would be pretty darn near a circle. Pretty trivial though to make API access require a paid token per account/user, and heavy Twitter users might well put down $1-10/month to use their client of choice.
Don't know, maybe just an artifact of the era. At the time on the web in general it just seems like there was this real aversion to any sort of paid offerings even if they were pure bonuses for heavy users with no actual content hidden at all. That's changed a lot since then, but still particularly for a company desperate for hard revenue and facing controversy over a specific somewhat power-user feature, a bit curious they didn't just try to monetize it. Doesn't seem like an honest presentation of that would even bother that particular subset, certainly not more then having it axed entirely.
> Twitter seem to have an institutional blindness towards the importance of APIs.
Which is especially weird for Twitter. Their official iOS client was a third-party API client they bought. Third-parties created @replies, #hashtags, etc. If anyone should recognize the important of third-parties using APIs, it should be Twitter... yet they've been probably the most abusive of the large APIs.
> Facebook’s strategy of becoming an integral part of other company’s products was key to them becoming a utility. Twitter was on that same path prior to their limiting developer API access.
No, not really on the same path. If Facebook was strictly a status update website, then the comparison would be proper. But Facebook's platform was rich with content and varied features. That's what let its API system become such an enhancement: Other sites would integrate Facebook into their own platform for a feature or two, but people would return to Facebook proper because it allowed them to see those features _among other features_. In the end, regardless of their intent, websites consuming the Facebook API were essentially being integrated into Facebook, and not the other way around.
Twitter, on the other hand, _is_ pretty much a status update website. And if it kept its API open, it would have been a much different story than Facebook. No one would have a reason to return to Twitter, they would simply continue to visit the sites/apps that integrated the tweets. Whatever ads Twitter had would score even less clicks than they do now. It would, perhaps, integrate Twitter into the ecosystem more than at present, but I doubt it would open up much opportunities for revenue.
All that is, of course, conjecture. Still, I have a hard time seeing the Twitter API leading to something more.
Twitter had published an application programming interface (API) for its service. Using the API, I wrote some software to automate the posting, such that everything would be timed correctly. I just had to push a button and watch. We named the project “Twittering Rocks.”
It ran successfully in 2007, and thanks to the software, it would be easy to run Twittering Rocks every Bloomsday. Which we did, in 2008, and 2009, and 2010. Then it broke completely and hasn’t worked since.
It broke, surprisingly, not because Twitter arbitrarily decided to screw developers. It was because of the migration to OAuth, which, if memory serves, just happened to coincide with the beginning of the period in which Twitter decided 3rd-party devs were screwable.
The conclusion nonetheless is apt:
How many apps on your phone don’t work properly anymore? Software breaks all the time.
> "If you wrote a client that exposed twitter to new markets or something that added value to Twitter"
That's exactly what happened here. Twitter does not currently have a native Win8 client, and a native client has always been a value-add for Twitter's users - many people prefer to have an always-on Twitter widget on their machine that pushes messages to them, over a browser window they have to poll.
I haven't used this software myself, but it certainly seems like something that is welcomed by Windows users and improves the experience for the relevant set of Twitter users.
The root problem here is unsurprising: for many web startups what's good for users is not good for the company. The modern, ad-driven web company is a precarious balance between tending to the sheep and throwing them at the wolves as hard as you can.
> Or you have appliances that got made years ago when Twitter integration was the fad of the day - I 'member there's a fridge out there that showed tweets on its screen
Most of those are probably already broken. Twitter dropped support for most third-party API clients a few years ago.
>concluding "don't build anything for Twitter" is just throwing a temper tantrum.
Not really. They led people on, over the years, into building on their API. People spent a lot of time and money building Twitter clients. Then they pulled the rug out. Why would you build anything using an API that could get arbitrarily locked down in the future?
> That upper-right quadrant also includes, of course, "traditional" Twitter clients like Tweetbot and Echofon. Nearly eighteen months ago, we gave developers guidance that they should not build client apps that mimic or reproduce the mainstream Twitter consumer client experience."And to reiterate what I wrote in my last post, that guidance continues to apply today.
> They've always meant apps that offer more or less the same functionality as official Twitter clients.
No, it started out that way, but then the functionality of the official Twitter clients was expended, and then they redefined it to be so broad as to potentially hit anything that tweeted, and they they went farther still and started going after API keys for things that just consumed the data for their own ends.
> Facebook has also done this repeatedly ... They just make breaking changes to production APIs all the time.
They do, but that doesn't slam the door shut on a developer/business purely for the sake of slamming the door shut on a developer/business.
From what I've seen, Facebook encourages API usage. Twitter encourages it until you make money, then they shut you down - often stating they're building a similar app/service and you'd be competing with them -- only then to never launch said app/service.
Twitter as a platform isn't worth much (as evidenced by year after year of not turning profits). The value in Twitter is the data - but they are locking it away.
Why not go the Google route and charge for API usage over a certain threshold. Twitter could stop caring what users do with the data, and make money as their ecosystem grows and becomes more successful.
> What Sarver said to developers today was direct: If you don't want to get burned, don't build pure-play Twitter clients. And if your app displays and sends tweets, make sure it looks and feels like Twitter.
> "Developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience," he wrote.
> "The answer is no."
Twitter to Devs: Don't Make Twitter Clients... Or Else [2011]
"I continue to not understand how Twitter has managed to trick an entire generation of developers into believing they need Twitter's permission to develop a third-party Twitter client. "
It's Twitter's API, and Twitter's servers.
"Has the law changed in some noticeable way to make reverse engineering the official Twitter client and extracting their first party keys for purposes of interoperability suddenly illegal?"
If you don't have permission to use someone else's stuff, you don't use it. We were all taught that in kindergarten.
"We used to do this all the time"
The fact that you abused other's web servers back then doesn't mean that it was right then or now.
> Twitter's developer API followed a typical pattern: do anything you can to get traction for your platform. This includes being "open" to encourage developers to build stuff on your platform. Then, when you don't need them anymore, ditch them.
From my recollections.. Twitter was a company that had a user base, but no plans or strategy to become actually profitable off that base. They, like many companies at the time, seemed to assume that if you just build the big "next generation open platform" that money would just start falling from the sky... somehow.
Ultimately, the red line meets the black line, and you have to turn to VCs who push you into the most obvious solution: Shut down all the "open platform" dead weight and start pushing advertising.
I don't think these are intentional moves but rather the natural consequence of certain types of silicon valley business "plans."
> I am talking about their FREE streaming API that let's you stream millions of tweets per day. I am just trying to raise awareness about how easily people can pull user data en masse from Twitter, which is very relevant to the article. It's public, but people still don't realize just how easy it is to do.
Yes, that's an endpoint off stream.twitter.com. It's not only limited in terms of how much relevant info you'll be able to access (in the context of the original post), but also heavily rate-limited for clients.
I agree that it's confusing that Twitter has so many different components of their API which use overlapping names, but I've looked into this extensively because, as I mentioned at the outset, I wrote the client libraries for these and still maintain them.
> They never "locked it down", they just rate limited some vital endpoints and never bothered to add endpoints for new, important features.
More importantly: they introduced a lifetime cap on the number of OAuth tokens that applications could create, which meant a lifetime cap on how many different users a Twitter client could support. Once you hit your Nth user, you could never have a new person authenticate that client.
That killed off basically every decent third-party Twitter client.
It's fascinating the Twitter we have today and the Twitter from that era are even considered the same app. I wrote a simple Twitter client in Cocoa and Python and even NodeJS. It was such a simple way to get a working, functional, usable demo going that you could immediately show to friends.
Then they realized it's impossible to make money advertising this way and shut it down.
reply