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