Twitter and developers, A Love Story

To say that Twitter and third-party developers have had an ambivalent relationship over the last couple of years is a massive understatement. Twitter has been undergoing a deep transformation of its business to one that makes sustainable sense as a public company.

Yes, Twitter will tell you that it’s not preparing for IPO, but its recent acquisition of hardcore legal staff and modeling of its revenue stream around the ‘shareholder-friendly’ advertising business says otherwise. An understandable, predictable revenue stream and risk limitation are two core issues that would need to be resolved before Twitter would be able to become a publicly traded company.

And that’s where the trouble started with developers. I’ve written something about those troubles before, you can read that here for the back story. But, today some news about Twitter refusing to allow a Windows 8 app called Tweetro more than 100k user tokens has brought up the discontent that many developers feel towards Twitter once again.

Tweetro’s developers were taken by surprise by the 100k limit, but, as someone who has covered these changes in Twitter in excruciating detail over the past few months I can tell you that I don’t know of any other developers who were. Twitter made it clear that 100k tokens was enforceable as of the announcement in August.

What it did say, however, which caused the Tweetro folks to hold out hope that they could get the limit lifted, was that “you will need our permission if your application will require more than 100,000 individual user tokens.”

This implies that Twitter would be flexible about the limits, but in all of my discussions with developers, and I’ve had a lot of them over the past few months, I’ve never seen evidence of them doing so. And they were not flexible with the Tweetro folks, even though there is NO official Windows 8 client from Twitter (it has said it is working on one).

Twitter’s response to Tweetro is very clear about the fact that they do not want more client applications developed for the platform (emphasis ours):

Thank you for reaching out to get clarification on our developer policies. As you know, we discourage developers from building apps that replicate our core user experience (aka “Twitter clients”). We  know that there are developers that want to take their passion for Twitter and its ecosystem to unique underserved situations. As such, we have built some flexibility into our policy with regard to user  tokens – which went into effect September 5th, 2012.”

“…Unfortunately, It does not appear that your service addresses an area that our current or future products do not already serve. As such, it does not qualify for an exemption.”

The future products bit of that is key. Twitter is saying ‘we are building a Windows 8 client, and we already told you we do not recommend you build clients’. Pretty clear, even if it’s not something that developers would like to hear.

Since May of last year, Twitter has been ‘discouraging’ people from building apps that ‘replicate our core user experience’. In fact, if you go back to the original May, 2011 post from Twitter’s Director of Platform, Ryan Sarver, it’s brutally clear what the company would be welcoming and not welcoming in the future:

 Developers have told us that they’d like more guidance from us about the best opportunities to build on Twitter.  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.

This isn’t anything new, and most developers of Twitter apps have been watching the development of Twitter’s allergy to third-party clients with avid attentiveness over the past year.

What DID happen, however, was that Twitter pulled back from this hard-line stance on third-party developers. In a post in September of last year, Twitter Chairman Jack Dorsey allayed fears that it was going to cut off developers entirely saying, “Our ongoing commitment is to give you the structure, tools, resources, and support you need to build your businesses as you leverage the power of Twitter.”

In the end, though, this post was not a notice that Twitter would welcome clients, just that it would like to see developers continue to work with it. I’ve said it before, but it warrants another mention:

• Here’s what Twitter doesn’t want: things that look like Twitter.
• Here’s what Twitter does want: things that use Twitter data.

I’ve talked to developers about Twitter’s stance a lot over the past few months. Hours in chats and on the phone, just listening and talking and trying to get a feel for what they think about the changes and how it will affect their livelihood, and here’s what I can tell you.

• Twitter decided to not welcome third-party clients in early 2011. It knew it needed to own its tweet-display experience in order to grow its product in the ways that it wanted to.
• Those ways are definitely IPO-friendly, regardless of what the company says publicly. They focus on the ad-friendly expandable-tweet Cards.
• Over the summer and fall of 2011, Twitter had a shift in internal sentiment that slowed the public and private stance towards eliminating third-party clients. That shift also brought a renewed openness and directness of communication with developers. Twitter communicated well, responded to developer questions privately and was generally helpful with many issues.
• That shift swung the other way this year, culminating in a warning shot in June of this year and the hammer drop in August.
• The announcement post in August was confusing, written in business-jargon that didn’t do anything to engender support or good will from developers or anyone else.
• Many developers felt, and still do feel, betrayed by Twitter, a service that they helped shape with their efforts.
• Throughout the last few months, I have heard nothing but positive comments about the communication between Twitter and developers. Simply put, Twitter is not ignoring or intentionally misleading any developers that I know of. That doesn’t make their policies more palatable to many, but, criticism where due.

The sad thing about this whole progression is that developers loved Twitter. I mean, really loved Twitter. They liked making things for it, they helped pioneer everything from the bird icon to the use of the word ‘tweet’. They were its first users and its constant advocates when everyone still thought it was about tweeting your lunch or your poop. Now, it’s gotten much harder to love.

Marco Arment wrote a strong post about this and encapsulated some thoughts that I had as well, but draws an interesting conclusion:

The real rule, if Twitter was honest and direct, is simple: “We don’t permit anyone to exceed the limit unless we feel like it.” But even then, it would be stupid for anyone to build a business on Twitter with such unstable footing. And if your plan is to stay under the 100,000-token limit, you’d be a fool to believe in the safety and longevity ofthat exemption.

The effective rule, therefore, is even simpler: “Don’t build anything for Twitter.”

If you’re building a client app, I agree with Arment 100%. As far as what I’ve seen, heard and understood over the past several months, building a Twitter client is a dead-end street. Do not do it.

As far as other developers that are using Twitter’s API to provide either a whole service or a component service inside their app, I think that it’s still too murky to say whether they need to bail. Arment thinks they should, based on the way that Twitter is changing the rules about clients, but, although I understand where he’s coming from, I feel that it’s too early to call this one.

As of this moment, any developer working with Twitter’s API, whether it’s a client or another type of app that is currently in favor, can’t be entirely certain about their livelihood. Right now these apps may be on a path that runs parallel to Twitter’s business plan, but what happens when that path zags?

The company has already demonstrated vividly that it will not hesitate to cut off the  business of developers in order to do what it feels necessary to secure its future.

Currently, it seems that Twitter will always welcome any services that push data into Twitter, or leverage its data in ways that doesn’t detract from people viewing tweets there. But, from this point on, any Twitter-using developer — even one that isn’t building a client — should pay close attention to future changes in the API, and start hedging their bets.

Via: The Next Web