1. 63
  1.  

  2. 26

    I am mostly posting this so I can comment on it because IFTTT contacted me back in October for the same thing regarding my Pushover channel. Their wording was different when they approached me, though:

    If you aren’t able to complete migration of the Channel by Feb. 1, 2016, we’ll unfortunately not be able to support the current Pushover Channel after that date.

    I took that to mean they would still offer it but just not provide support for it. Maybe they meant to say they would remove it, but in either case, I had implemented a number of features in Pushover’s API since they released the Pushover channel years ago, and I was happy to finally move to their new developer platform so I could add support for those new API features.

    Clearly IFTTT has grown to the point where keeping up with every channel’s unique API is becoming unwieldy, and/or they are big enough that they feel confident in being able to dictate the terms of providing service to all of those channels. I have seen a ton of Internet-of-Shit products come out lately from large manufacturers that boast IFTTT support, so they must be operating in a favorable position these days.

    As for “Working for Free”, IFTTT has undoubtedly brought me more than a few paying users over the years, and continuing to have Pushover as an option on their site would only help me in the future, so I spent the few hours it took to implement a custom API for their site. Their developer platform website has some automated testing tools on it so it’s easy to “maintain 100% compatibility with the Developer Tool and the Service” as they require. Obviously a better solution would have been for IFTTT’s developer platform to have some kind of query builder so you could tell it how your API works in a programmatic fashion, rather than IFTTT creating the API and making every site conform to it.

    I do think it was pretty shitty of them to e-mail all those users and point the finger at Pinboard, though. I guess I was wrong in my initial assumption that they would continue to operate those legacy services and just not support them.

    1. [Comment removed by author]

      1. 11

        I think Maciej is taking an overly cautious reading of them, but he’s right to be cautious and upset about what they’re trying to force him to do.

        His first point about competing with them in the context of the entire paragraph is that you can’t use the developer tools or the IFTTT service to build a competing service, not that you can’t build a competing service ever, using your own stuff.

        The next point about content seems scary, but their end-user TOS basically says the same thing regarding “Ownership” of “Content” (“Content” defined as stuff going through the service). All of the content going from IFTTT to Pushover belongs to our mutual user anyway, so if they aren’t happy with that, they should not be using IFTTT (before or after the switch to the Developer Platform). I don’t think this makes things any worse for me as a developer.

        The patent thing only relates to the API between the site (Pushover or Pinboard) and IFTTT. Not sure what magic he’s worried about inventing in that narrow area.

        And of course, the agreement transfers to the company that will inevitably acquire IFTTT. Not sure how that’s a bad thing. You could revoke your channel at any time if you didn’t like where it was going (or just shut down your custom IFTTT endpoint).

        In the end, it’s not like breaking these terms (e.g., “not maintain[ing] 100% compatibility with the Developer Tool”) will get you sued, it would just get your channel shut down.

        1. 3

          The next point about content seems scary, but their end-user TOS basically says the same thing regarding “Ownership” of “Content” (“Content” defined as stuff going through the service). All of the content going from IFTTT to Pushover belongs to our mutual user anyway, so if they aren’t happy with that, they should not be using IFTTT (before or after the switch to the Developer Platform). I don’t think this makes things any worse for me as a developer.

          As an end user when I read things like this I tend to think “Wait, so if I use IFTTT to notify me that a friend has posted a picture on Twitter, and save that to my Dropbox, IFTTT owns the picture?”.

          Guessing from your reaction that I’m taking an overly simplistic view of things.

    2. 6

      Someone on HN also pointed out they require you to treat their dev tool with the same precautions as your most confidential information. For some people, including myself, that would be quite inconvenient.

      1. 6

        This is terrible, but Maciej has misinterpreted the clause about patents:

        And they assert the right to patent any clever ideas I have while doing that free work for them, even though I hate software patents:

        12. Patent License. Licensee hereby grants IFTTT a nonexclusive, sublicensable, perpetual, fully-paid, worldwide license to fully exercise and exploit all patent rights with respect to improvements or extensions created by or for Licensee to the API

        This isn’t how patents work and it isn’t what the section means. It means that if you patent any ideas related to the IFTTT service, they have a licence to those patents. Still shitty, but not as shitty as Maciej makes out here.

        (IANAL, TINLA)

        1. [Comment removed by author]

          1. 2

            Yes. They don’t just integrate with one company’s API, they integrate with many. The glue code that they’re now apparently trying to get others to write for them is their primary value.

            1. [Comment removed by author]

              1. 3

                So … yes, you could do that, and you’d be rebuilding the core of what IFTTT is (ingress for some APIs plus egress for some APIs with some way of connecting the two), plus some extra AWS things. There’s nothing stopping you from doing that, of course!

          2. 1

            So is there an alternative to IFTTT? Because I’m personally a bit frustrated by their lack of pebble support.

            1. 2

              The big player is Zapier, but you’re a little limited on number of recipes. Maciej recommended Botize. I’ve not heard of this one myself. A few quality listed ones here look of interest http://alternativeto.net/software/ifttt/

              1. 2

                Based on this list, Huginn seems like the best self-hosted, open source option.

              2. 1

                What does IFTTT have to do with Pebble?

                1. 1

                  Someone wrote an IFTTT do app for pebble and IFTTT requests it be removed. I suspect they’ve made their own replacement by now, but honestly I don’t even care.

                  1. 1

                    I could easily envision several scenarios where it could be useful. “If I get a tweet from JCS, display it on my Pebble” etc.

                    1. 2

                      Well you can’t talk to the watch directly, so usually something (IFTTT, Zapier, etc.) would just send a notification to an app on the phone (like Pushover), which would then show it on the Pebble.

                      Though now that you mention it, I wonder why Pebble hasn’t opened up an API to send notifications directly to their own phone apps to show on the watch, rather than a 3rd party app like mine that has to forward it to their app.

                  2. 1

                    Maciej points out the alternatives in the article. Zapier for one.