[timv]

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

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]

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.

[maxerickson]

Microsoft spent several decades devoting lots of resources to not breaking old software. Obscene things like sniffing binary names to support weird legacy behaviors. They did this because users don't like disruptions, especially when they are (or just seem) arbitrary.

Maybe IFTTT has good reasons for turning off the working integration. I haven't seen where they list them.

[chris_wot]

Funny you should say that: if there is a plugin infrastructure, I'd expect it to be running for at least a few versions of Excel with proper deprecation notice.

[adekok]

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

No. Because the situations are different.

Here, Pinboard did essentially nothing to get IFTTT to work the first time. IFTTT wrote the integration code, and has been maintaining it. They're now trying to push that effort onto other people.

i.e. They're trying to make YOU maintain code THEY wrote. Or worse, they're trying to make YOU write code which has no value for you, but value for THEM.

If you refuse to work for free, they will remove you from IFTTT integration... to the detriment of their own users.

> Of course they might do so for a couple vital ones to help jumpstart the integration system, but it's not black and white.

It is. Given their ToS, it's pretty damned black and white. IFTTT is pushing their development costs onto the platforms they pull data from. And then claiming that those platforms have to continue working for free, and that IFTTT owns the results of that work.

If you can't see a problem with that, I'm going to make you work for my company, for free, forever.

What? You don't like that?

Well... the same applies here.

[sushid]

Not the parent commenter but I can see how this would harm the product's image as you've stated. However, they're not forcing you to do anything. Technically, they're just saying they're not going to maintain their code anymore and it's up to you to continue or not.

It's as if you've gotten a lot of business to your small coffee shop because I've chosen to shuttle potential customers to and back from your shop. If one day I tell you I'm going to stop doing this, but you're welcome to pick up the slack, am I truly being unreasonable?

[timv]

> If one day I tell you I'm going to stop doing this, but you're welcome to pick up the slack, am I truly being unreasonable?

Well, if you (dishonestly) tell the customers that the shuttle is stopping because the coffee shop refused to work with you then you're absolutely being unreasonable.

And if you tell the coffee shop that they can pick up the slack, but they need to sign this one-sided, ridiculous contract that requires that you only use their approved bus company, and don't pick up customers from any unapproved stops, and accept all liability if something goes wrong, and pay for all maintenance and repairs on the bus, (including repainting it if/when the bus company changes their branding) and agree that all passengers are customers of the bus company not the coffee shop, and the bus service can chose to take them to a different coffee shop, and the bus company can discontinue the service at any time without notice, and you can't disclose the terms of this agreement..

Well, then you're truly being unreasonable. You're welcome to try it of course, but you can expect to be publicly called out on it.

[SZJX]

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.