3 ms·

> I apologize for any misunderstanding our communications today have caused I'm not so sure there is a misunderstanding. The facts seem relatively clear: - Y

by timv 11y ago

> I apologize for any misunderstanding our communications today have caused I'm not so sure there is a misunderstanding. The facts seem relatively clear: - You want services to implement your proprietary API so that IFTTT integration with their service runs more smoothly. - Your business success is predicated on other services providing those APIs, but you want them to do the work for no reward. - You have license terms that protect your interests, but not theirs. - If a service isn't interested in playing by your rules you'll remove them from IFTTT to the detriment of your own users. - You call Pinboard a "beloved service", but not so "beloved" that you're willing to support their existing API, just "beloved" enough to graciously allow them do build an implementation of your API. The only misunderstanding seems to be that you think that's somehow reasonable, and most of us don't. > we've been on the receiving end of platform changes too many times to count. I want to make sure we do it better You know that API changes are painful, so you want to push that pain onto services like Pinboard, by forcing them to maintain compatibility with your evolving API. > The changes we are asking for are indeed more work, but we know they will lead to a better Pinboard Channel on IFTTT Interpretation: We're expecting Maciej to put more effort in, but it will make our product so much better if he does! It's your product - shouldn't the effort be yours?

rtpg 11y ago
On the other side of the spectrum, do you expect Slack to maintain the Slack integration you write for your webapp? Do you expect Microsoft to maintain Excel plugins? Of course they might do so for a couple vital ones to help jumpstart the integration system, but it's not black and white. IFTTT is a bit different because this is their value-add. But is it so different that you can make a claim that in a context-free environment sounds almost absurd? On IFTTT I think it's kind of reasonable to expect them to do it, but at the same time the inversion does things like (for example) let me write an IFTTT integration to my own service. You could just as well have both (IFTTT writing integrations, and individuals writing integrations) I imagine. At one point integrating with IFTTT becomes a value add for both parties, and the delegation of "who should do this" is not obvious. I don't think it's super clearcut here.
- danpalmer 11y ago
  The thing is, integration is what IFTTT does. Their entire product is connecting different shaped pipes together. It's their core-competency. Sure, they got bitten by platform changes, but reacting to that was under their control. Now when the services change, they're going to have to wait for the engineering teams at the service providers to prioritise getting that integration working again. Excel isn't its plugins, Slack isn't its integrations, IFTTT is only its integrations.
  - rtpg 11y ago
    Integrations are a pretty big part of Slack. I agree that IFTTT is only its integrations, and them maintaining certain channels is definitely in its interests. But on the flip-side, IFTTT is an integration multiplier for any pipe. So you can make the pitch that your startup should write an IFTTT integration, because that really gets you 100 integrations (the truth is a bit more delicate of course). Another advantage is someone asks you "why isn't X inside IFTTT?" You can now actually fix the problem. I definitely understand repositioning to "IFTTT provides pipes, but you provide the data." It's much more scalable (helping to ensure that it'll be around for a while) and offers advantages on both side of the fence. 100 companies maintaining 1 integration is more straightforward than 1 company maintaining 100 integrations. And that means IFTTT can concentrate on making the pipes (the real value-add, because "consume this webhook" isn't interesting in isolation). Why they didn't do this and work for a way for their legacy (if unmaintained) channels to keep on working is a mystery to me though....
    - danpalmer 11y ago
      > Integrations are a pretty big part of Slack. I think I disagree. Integrations are a big part of Slack for tech companies, but Slack is doing well not because lots of small tech companies are using it, but because lots of bigger less-technical companies are. With them, I think it's transformational to have good instant messaging, not integrations. > I definitely understand repositioning to "IFTTT provides pipes, but you provide the data." It's much more scalable (helping to ensure that it'll be around for a while) and offers advantages on both side of the fence. 100 companies maintaining 1 integration is more straightforward than 1 company maintaining 100 integrations. And that means IFTTT can concentrate on making the pipes (the real value-add, because "consume this webhook" isn't interesting in isolation). But this is exactly my point, there isn't anything in those pipes, it's just an integration at each end. Sure there might be some tricky technical stuff to scale it (I don't know), but that's not the product. And I think 1 company having a core-competency of "plugging webhooks together" is simpler than 100 companies a) knowing another 3rd party API, and b) having to prioritise maintaining that integration highly enough that it matches the release cycle of IFTTT.
SZJX 11y ago
The transition definitely makes sense in the long term. The terms of services not so much. And that's where I think the controversy lies.

by timv 11y ago

rtpg 11y ago

On the other side of the spectrum, do you expect Slack to maintain the Slack integration you write for your webapp? Do you expect Microsoft to maintain Excel plugins? Of course they might do so for a couple vital ones to help jumpstart the integration system, but it's not black and white. IFTTT is a bit different because this is their value-add. But is it so different that you can make a claim that in a context-free environment sounds almost absurd? On IFTTT I think it's kind of reasonable to expect them to do it, but at the same time the inversion does things like (for example) let me write an IFTTT integration to my own service. You could just as well have both (IFTTT writing integrations, and individuals writing integrations) I imagine. At one point integrating with IFTTT becomes a value add for both parties, and the delegation of "who should do this" is not obvious. I don't think it's super clearcut here.

danpalmer 11y ago
The thing is, integration is what IFTTT does. Their entire product is connecting different shaped pipes together. It's their core-competency. Sure, they got bitten by platform changes, but reacting to that was under their control. Now when the services change, they're going to have to wait for the engineering teams at the service providers to prioritise getting that integration working again. Excel isn't its plugins, Slack isn't its integrations, IFTTT is only its integrations.
- rtpg 11y ago
  Integrations are a pretty big part of Slack. I agree that IFTTT is only its integrations, and them maintaining certain channels is definitely in its interests. But on the flip-side, IFTTT is an integration multiplier for any pipe. So you can make the pitch that your startup should write an IFTTT integration, because that really gets you 100 integrations (the truth is a bit more delicate of course). Another advantage is someone asks you "why isn't X inside IFTTT?" You can now actually fix the problem. I definitely understand repositioning to "IFTTT provides pipes, but you provide the data." It's much more scalable (helping to ensure that it'll be around for a while) and offers advantages on both side of the fence. 100 companies maintaining 1 integration is more straightforward than 1 company maintaining 100 integrations. And that means IFTTT can concentrate on making the pipes (the real value-add, because "consume this webhook" isn't interesting in isolation). Why they didn't do this and work for a way for their legacy (if unmaintained) channels to keep on working is a mystery to me though....
  - danpalmer 11y ago
    > Integrations are a pretty big part of Slack. I think I disagree. Integrations are a big part of Slack for tech companies, but Slack is doing well not because lots of small tech companies are using it, but because lots of bigger less-technical companies are. With them, I think it's transformational to have good instant messaging, not integrations. > I definitely understand repositioning to "IFTTT provides pipes, but you provide the data." It's much more scalable (helping to ensure that it'll be around for a while) and offers advantages on both side of the fence. 100 companies maintaining 1 integration is more straightforward than 1 company maintaining 100 integrations. And that means IFTTT can concentrate on making the pipes (the real value-add, because "consume this webhook" isn't interesting in isolation). But this is exactly my point, there isn't anything in those pipes, it's just an integration at each end. Sure there might be some tricky technical stuff to scale it (I don't know), but that's not the product. And I think 1 company having a core-competency of "plugging webhooks together" is simpler than 100 companies a) knowing another 3rd party API, and b) having to prioritise maintaining that integration highly enough that it matches the release cycle of IFTTT.

SZJX 11y ago

The transition definitely makes sense in the long term. The terms of services not so much. And that's where I think the controversy lies.