[danpalmer]

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]

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]

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