Why IFTTT being forced to remove its Twitter triggers is a red alert for developers

by Matthew Panzarino — in Twitter

Why IFTTT being forced to remove its Twitter triggers is a red alert for developers

We just got word this morning that the very cool internet glue service IFTTT was being forced to remove any of its Triggers that have to do with Twitter.Yes, IFTTT is a service beloved by tech nerds, but this change also signals something important about Twitter’s future relationship with developers — something contrary to its previous statements about its recent API changes.

IFTTT, if you’re not familiar, is a service that allows you to hook together cool Internet things like Twitter, Facebook, Pusher, SMS, RSS and many more to do interesting stuff. You could, for instance, push a tweet out when an RSS feed is updated, or pull down your tweets to archive them or, and this is a big one, cross-post tweets to other services.

New York, meet the world’s tech scene

5,000 Tech leaders are coming to NYC this November to learn and do business. This is your chance to join them.

Check it out

Well, earlier today, IFTTT CEO Lane Tibbets said that it would have to stop offering the Triggers related to Twitter. “As a result of these changes, on September 27th we will be removing all Twitter Triggers, disabling your ability to push tweets to places like email, Evernote and Facebook. All Personal and Shared Recipes using a Twitter Trigger will also be removed.”

Here are the Triggers that will be removed from IFTTT:

Once you pick a Trigger, you choose an Action Channel, which can be any other service, including SMS, Dropbox or other services like Facebook, WordPress, Storify or LinkedIn. Some people use these combinations to post to other networks and some just use them to archive tweets. Either way, they’re being used to pull tweets out of Twitter rather than to publish them to Twitter. Those actions that allow users to push tweets to Twitter will remain.

So yes, no real surprise there, we knew Twitter wanted people posting to it not elsewhere, and that it wants people looking at Twitter’s apps to do that.

But here’s the thing. Back when this whole Twitter API boondoggle was hitting hard, Twitter had to do a lot of work to clarify their blog post because they didn’t make it clear that a lot of the restrictions had to do with apps that act as clients for reading Twitter, not third-party ecosystem apps that use Twitter’s platform to post tweets and do other cool stuff.

Here’s how I put it:

Twitter’s developer ecosystem basically breaks down into two halves. Those making clients that feel like ‘better’ or ‘different’ versions of Twitter like Tweetbot or Twittelator Neue, and those who integrate Twitter into their apps and services.

The rules limiting clients to 100k or 200% of their current number of users, for instance, do not apply to apps that utilize Twitter in ways that leverage its data, like Klout, promote the use of features of Twitter, like Favstar or collect Tweets in ways that display them exactly to Twitter’s standards, like Storify. There are even some clients like Hootsuite, which Twitter says falls into ‘enterprise’ use, which are deemed ok.

Twitter even posted a supplemental document about its updated ‘Rules of the Road’ for developers explaining that ‘traditional Twitter clients’ were discouraged.

But, if you read that document carefully, you’ll see the clause that got IFTTT in trouble: “Don’t resyndicate data. If your service consumes Twitter data, don’t take that data and expose it via an API, post it to other cloud services, and so on.”

That clause isn’t new, but the enforcement of it is. In his post on Twitter’s Developer blog back in June of 2012, Michael Sippey states “
we’ve already begun to more thoroughly enforce our Developer Rules of the Road with partners.”

Basically, Twitter doesn’t want anything that you post to Twitter to go anywhere else. And apps that are not Twitter clients are NOT safe, by any means if they violate any of Twitter’s policies.

This means that many third-party developers who thought that their complimentary services, which did not duplicate the features or feel of clients at all, were safe under the new rules will have to take a very hard look at their apps.

I called it then:

Sure, 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 run roughshod over the business of developers in order to do what it feels necessary to secure its future.

“I think we’ll look back on the last few years as an incredible time for Twitter app ideas and UI innovation,” Tweet Marker developer Manton Reece told me at the time. “We had a good run. I won’t stop developing for Twitter tomorrow, and I’ll keep Tweet Marker running, but the platform doesn’t have a future for the kind of things I want to build.”

His fears, which I know for a fact are shared by many third-party Twitter developers, appear to have been confirmed:

At this point, any third party developer using Twitter’s platform for their product should probably take a very hard look at the capabilities of their apps. If there’s any chance that they might overlap with Twitter’s desire to be the only way that people read tweets
it might be time to get out.

Read next: The truth about Twitter

Shh. Here's some distraction

Comments