Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> 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]

https://mashable.com/archive/twitter-api-clients



sort by: page size:

"More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.".

How can a company who's user base has grown to such an amount because of third party clients say something like this? Talk about showing a little appreciation. As someone who develops a Twitter client, it is a huge kick in the teeth.


I believe that was pulled from Ryan's email:

"... developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no." ... "If you are an existing developer of client apps, you can continue to serve your user base"


> 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.

https://dev.twitter.com/blog/changes-coming-to-twitter-api


> it's just twitter but you can write and use custom clients and feed algorithms

Compelling for whom? For developers? I’m not sure anyone else will care.


> 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.


> 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.


This would have been a savvy move from Twitter about say, 4 years ago when it was clear people were going to be sharing a lot of images.

As regards developers, their message is to not build "client apps that mimic or reproduce the mainstream Twitter consumer client experience". However, the mainstream Twitter client experience may at any time be expanded to include whatever you're doing already. That's always a danger when building on someone else's API like this, but the 'inflection point' comes when a company actually starts replacing 3rd party developers' tools with official products.

That should help developers decide what to do next... In my case, it's more clear that I don't want to have anything to do with the Twitter API.


> 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.


I'm not quite sure about that. Check this part:

"More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.

If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service"

This sounds to me like they don't really want "normal" Twitter apps anymore, but have just grand-fathered in the existing ones, while opening the door to closing them down if they don't follow the guidelines.


Twitter did the same thing to devs using their API to make apps.

>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?


Which basically amounts to "Don't write a twitter client" right now.

Well, I think the point is, building Twitter clients use to be allowed, even encouraged, by Twitter. And now it's a big no-no. So even though they're only restricting new client development, the restriction affect anyone developing with the Twitter API. What's not to say the type of app you're building today won't be restricted tomorrow.

Let the market decide. If developers are making clients that are worse than the standard, people won't use them. What is Twitter's product here?

> And it might be deterrent against people trying to build popular alternative client that might compete with main twitter app.

That's horrible for users.

Twitter's iOS app is a third-party app they bought because it was so much better than their own at the time. https://en.wikipedia.org/wiki/Tweetie


> Oh, I didn't mean letting the clients support them, I meant making the clients support them and feature them how Twitter wanted them to.

So did I.

No feature no key, no key no third party client.


A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities.

Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themselves did well. Many raised millions of dollars in VC funding to make vibrant companies around the Twitter ecosystem. Things were going well.

Then Twitter became greedy. Twitter decided to destroy the very companies that grew Twitter's user base. They changed their TOS monthly outlawing various product categories. They banned clients. They put restrictive quotas on their APIs to starve out companies so they could reap their revenue for themselves. Hundreds of products fell. Millions of developer hours were lost. The Twitter ecosystem shrank and so did Twitter's user growth.

So if you're thinking about building anything with this company then be warned. If anything you've built is remotely popular, then it is only a matter of time before they come to pillage whatever you've built.


Did you miss when Twitter explicitly told developers not to make any more third-party Twitter clients? The situation is simple, and just as the comment you replied to states.

> 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.

next

Legal | privacy