Hacker News Reader

Comment by lindentibbets | Hacker News Reader

I am the CEO over at IFTTT. I apologize for any misunderstanding our communications today have caused. I built the Pinboard Channel on IFTTT and have maintained it for years. I am also a paying customer of Pinboard! I’ve built for hundreds of platforms and any changes to those platforms by default suck. At IFTTT, we've been on the receiving end of platform changes too many times to count. I want to make sure we do it better. Pinboard is a beloved service. Every service is, on IFTTT or not. We care about the people who use them and build them. The changes we are asking for are indeed more work, but we know they will lead to a better Pinboard Channel on IFTTT in the long term. I'd love to see Pinboard stay on IFTTT and am willing to give them the time they need and even come over to help myself!

View on HN

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

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.

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.

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

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

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

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?

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

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.

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.

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.

My hobby: role-playing how I would respond as the CEO if my company was getting skewered on HN. Here is my version!

---

I am [not] the CEO over at IFTTT. We messed up. Big time.

Pinboard -- and other services developers love -- played an important role in our success thus far and we dropped the ball with the roll-out of our new platform. We have a shared incentive: to make channels work reliably for our end-users. To both stabilize existing channels and to allow new services to connect to IFTTT, we are publishing documention for a standard API that any new channels will need to conform to.

Going forward, we will be allowing existing channels to run on the legacy platform. Additionally, we will be reviewing our ToS to clarify out intent. We're not keen on legalese, but it is part of the game when doing integrations between third parties.

To maciej, I've reached out personally via email to apologize for the unclear messaging to our users. If you would like to give us a chance to make things right, we would be grateful and happy to help resolve any other outstanding issues.

Bingo.

Is there a reason legacy support cannot occur? I haven't seen it addressed.

Legacy support is work, and ifttt would rather not do it, of course!

Bookmarked so you can write the post if and when I mess something up. Big time.

Damn, that is good! I have reached out to Maciej as well.

You do not seem like a very serious CEO.

Being a "very serious CEO" isn't necessarily a good thing.

I'd say it is the only right way to act when you have been called out on sending scary legal contracts and bullying services into working for you for free.

I think your hobby could be a MVP for the first CAaaS -- CEO Apologies As A Service.

(If you act fast, Theranos could be your first Enterprise customer.)

Funny! Now for a business name... "Palms Up, Inc."? Or maybe just "Public Relations LLC."

Sorry.co....

> I’ve built for hundreds of platforms and any changes to those platforms by default suck. At IFTTT, we've been on the receiving end of platform changes too many times to count. I want to make sure we do it better.

I'm reminded of the Joel Spolsky blog post Where there's muck, there's brass: "The trouble is, the market pays for solutions to gnarly problems, not solutions to easy problems." Presumably IFTTT's value was derived from writing these sucky adapters. Now, you want the target sites to write them and your value is derived from this legal agreement, which gives you ownership of these newly outsourced sucky adapters. You have to see how that rubs people the wrong way. If it's an open standard, then at least you're competing on a level playing field and the work these target sites are doing is not all solely for your company's benefit.

Nobody is even answering our emails/applications for an IFTTT channel so I'm going to shamelessly hook in here and ask: who do small companies (that's what startups are, right?) have to bribe to get bigger companies to even look down at us and exchange an email or two ?

And PLEASE don't tell me to "just fill out the form at http://ifttt.com/platform", tired of that already. We have hundreds of thousands of active users of an IoT service and you're just ignoring us.

PS: I'm grossed out by the fact that I had to resort to a HN comment to try to get someone's attention. Go ahead and downvote to the abyss.

Our apologies! We are smaller than you think :) Send me an email at my first name at ifttt.com

Could you clarify if you actually have someone that is responsible for reading and responding on the official contact channel (http://ifttt.com/platform) for "Partnership" Inquiries?

I've found that if you ever want to contact a company, find the appropriate person and email them. Collectively owned company emails are terrible because they often don't have a single point of responsibility.

Also for github repos, project maintainers, email if you want a response, don't use an issue or the wiki or form. I just got a minor rails gem updated today that had people complaining about the lack of updates in issues by emailing the account owner.

> Go ahead and downvote to the abyss

https://news.ycombinator.com/newsguidelines.html

> Please resist commenting about being downvoted. It never does any good, and it makes boring reading

Zrgiu_ , I'd recommend looking into writing a Node-red node. That way, your work stays yours, and integrates in a wider open source community.

Your work should stay yours, and as current as you choose. You will have to deal with the initial npm politics, but that's better than the IFTTT contract presented...

I'm a pinboard user, and an IFTTT user. I've also made a few recipes on IFTTT including the pinboard > Google Calendar one.

The sum of your comments on here mean that I'll be looking to reimplement all of the IFTTT recipes I use on Botize.

You've stood by your legal team and defended the ToC, in addition to how this has been communicated and handled, and what it is you're trying to do.

Are you really trying to assert ownership of content as it passes through the APIs on your site? If not... why is that even in there? If you are, then there is no way I can keeping being a user of IFTTT.

It seems to me, that when these HN episodes happen that it would be a good time to pause and wonder if the internal bubble at IFTTT in which this was thought a good idea, actually produced an externally viable good idea. I think in this case, it did not.

Agree with your last point: like it or not, these moments are pivot points and it's very likely not the right answer to try to ignore them and continue to plow ahead full steam.

> At IFTTT, we've been on the receiving end of platform changes too many times to count. I want to make sure we do it better.

I've never used IFTTT, but my understanding is that this is the biggest value IFTTT provides - tying together a set of normally incompatible services. If you're now pushing this work onto the services themselves what is the value add that IFTTT provides? And wouldn't the internet be better off if those same sites adopted a shared, open API that could be used by anyone instead?

Connecting to IFTTT provides some value to the sites too. It's not like IFTTT is pillaging the client sites here. Clearly most of the services have seen enough value to do these upgrades, not just once but multiple times.

Being CEO of IFTTT must not be a very demanding job if you offer to come over to every service that connects to your platform, in order to contribute to coding their API.

Joking aside, Maciej isn't asking for "more time", he's asking for:

1. Money, if he has to do your work for you

2. Some kind of guaranty that your undocumented, private API won't change without notice in the future, rendering all this work useless

3. Legal terms that would be acceptable, ie that would not attempt to rob him blind of all intellectual property regarding any work in relation to your service (from which he derives exactly zero money!) and that would not prevent him from competing with you.

Your answer so far does not even attempt to address any of those points.

Actually, all I want is for existing IFTTT recipes that use Pinboard not to break.

I am fine with IFTTT discontinuing support for my site because of our diverging views on whether a service like IFTTT should be a platform or a roll of duct tape, but the stuff people have duct-taped together should stay duct-taped together.

This whole thing is exactly my problem with duct-tape as a service. Stuff a Huginn docker container (FOSS IFTTT) on your own server and bam, personal duct-tape.

In case it's not immediately clear, this is Maciej from Pinboard. Note the handle is the same as his blog's name.

I think the other part here, is that IFTTT is making it sound blackmail-y...

IFTTT to users: Weeeeelllll, we had great integration with X service, but they refuse to play ball with us any more. And now, their connector broke, and they refuse to fix it!

It makes you look bad to the users. And if you refuse this faustian 'deal', you're slandered and stuff breaks. And that break isn't because software rot, but because they broke it. And then blame you for it.

Yeah, blackmail is the right word.

Having spent countless hours working with third party apis that are poorly documented and business critical I can understand how unexpected changes can be frustrating. But asking people to do things your way with no incentive is even more frustrating for everyone. It comes off as you not respecting their time or the product and apis they have already built.

We very much respect Pinboard's time and are willing to give them just about as much of it as they need. Am willing to spend our time as well! We are looking to improve all of these integrations over time, beyond what their API can support and the best way for Pinboard to do this is to own that integration completely.

OK, but considering that people don't work for free to help others make money do you think it's reasonable to ask maciej or anyone else to do what you're asking them to? You say "it's the best way if they own the integration" as if owning it and the headaches it entails helps developers at all. Why not go for the suboptimal way and maintain it yourself, like you have been all these years?

I get that your service looks bad when integrations break but you could make a different contract requiring developers to give you a heads up in advance of any API changes and then you do the work of keeping the integrations working.

I respect your time as well. Please, take as much of it as you need. I'm generous that way.

> We very much respect Pinboard's time and are willing to give them just about as much of it as they need

Demanding someone make changes and then offering them as much time as they need is missing the point. It's not the deadline that's offensive, it's the request for free work that you benefit from.

"we've been on the receiving end of platform changes too many times to count."

But this is the value you provide, this is your raison d'etre.

So true. IFTTT is the glue not the paper. If they wish to go ahead and glue the papers accurately, it's not the paper producers job to make sticky paper.

This is a legal, future setting precedent for ifttt and they're gambling on weaker websites to get squeezed.

"I’ve built for hundreds of platforms and any changes to those platforms by default suck. At IFTTT, we've been on the receiving end of platform changes too many times to count."

Isn't that the entire premise of your service, providing this glue? Yeah, it's painful work. That's why people like your service! Sure, it would be great for you if the other services would do some of the work. But I'm guessing that you would not go along with Twitter requesting all intellectual property rights to your integration code for the right to use their API. Why would you request it of the services that integrate with you?

But the biggest problem here is that you changed the game. You created and maintained the Pinboard integration. You should own up to not wanting to maintain it. The message you sent to Pinboard users about your decision was... "misleading" is the nicest way to put it.

On one hand, you can justify the work as a part of making a more reliable platform without per-service shims, but presumably you could have asked the services to adopt a better open API rather than IFTTT-specific integration.

But why did you ignore all the commentary on your TOS? Are you endorsing those terms as the company you want to be?

Our API is not yet open, but we very much want it to be soon. I stand behind our TOS and I agree that we can make it clearer.

>I stand behind our TOS and I agree that we can make it clearer.

It's already very clear.

Having read what was posted of the Terms of Service document, the document is saying that IFTTT shall own all rights, title, and interest in my content... You stand behind that?

The fact that IFTTT claims to own all the content that flows through it, even though it did not itself create any of that content, is ridiculous. That alone is reason for no one to ever use this service.

Your TOS is a disaster. Anyone agreeing to it is an idiot.

Also, the developer pays YOU $3000/year to write an integration for YOU? WTF?

I run a service larger than yours. Not a chance in hell I'd agree to what you're asking there. You need to reorient your thought process around mutually beneficial partnerships instead of acting like you're doing someone a favor by letting them onto your platform. It'll work out better.

I'm a mere user of IFTTT. And the more I read this train-wreck of a thread, along with what you're putting developers through, I'm done.

All of my further work will be done purely with local instances of Node-Red and Apache NiFi. It may not support everything IFTTT does (and I know that), but what I will have will just work.

And in all honesty, all "* as a Service" companies give me the heebie-jeebies, because I know you (collectively) can do the stunts shown here.

Edit: account deleted on IFTTT as well. The less I am a serf on anothers' system and the master on my own (Node-Red), the better. Enough of lock-me-in closed APIs.

The things you are saying here sound like your attitude is in the right place, but did you actually read the TOS your legal team sent out?

Yes I did. Agree that we could make some improvements

As the CEO, if you think you could have made some improvements, then I wonder how this contract got sent out to valued partners? Can you share with us your plan for fixing this state of affairs going forward?

Making those improvements before sending it out would have been smart I think.

Some of us care a great deal about license agreements for different reasons.

This isn't just about time, though that's also really cheeky of you since the plumbing is the sole value you provide, who would sign insane terms like this?

You shall not...use the Developer Tool or Service in conjunction with a product or service that competes with products or services offered by IFTTT

IFTTT shall own all right, title, and interest (and all related moral rights and intellectual property rights) in and to the Developer Tool, Service, and Content.

Perhaps Pinboard should come up with some equally crazy terms and ask you to sign it in order to use their service.

>we know they will lead to a better Pinboard Channel on IFTTT in the long term

Well, reading Maciej writing it sounds like you will no longer be connecting to his backend while Botize will. These things happen. Sometimes it's best just to move on.

Until you change your terms of service and move to publicly-available APIs, your actions speak louder than comments on HN.

Maybe don't throw away the current integrations that work for magical new platform, but instead work collaboratively so that both parties plan and work together on channels to manage change from a position of trust? devops for vendor relationships. Instead, seeming to take an adversarial tone isn't going to benefit either service. I would consider rolling back the developer TOS to something equitable and sign mutual NDAs to share support / source for channel integration code and make publishing stable APIs in both directions a priority. Otherwise, channels will disengage as we're seeing right now and it hurts the platform because it gives the appearance of shifting externalities to everyone else, even if that is not the intention. It comes across as bullsh!t.

>> Every service is, on IFTTT or not. We care about the people who use them and build them. The changes we are asking for are indeed more work, but we know they will lead to a better Pinboard Channel on IFTTT in the long term.

This struck me as remarkably hollow. It doesn't even go into the issues of the strong Terms of Service conditions. Maybe, it's the juxtaposition of having just read a reddit thread about CEO interaction [1], but, to me, this kind of message is worse than silence. It's bad enough to get those fake "warm", "friendly" emails from startups trying to stop churn, but at least those are automated.

I like Maciej's style because there's no mediation of business-speak, it's just the message plus some eccentric local color/flourish. Shoot straight or just step aside. Silence is an option.

[1] reddit discussion about CEO interaction, interesting tangent https://www.reddit.com/r/oculus/comments/4cfd2h/im_founder_o...

Quick update: We will be keeping Pinboard on IFTTT. Here is an email we sent out to Pinboard customers this afternoon explaining! http://ift.tt/keepingpinboard

It's awfully early to gamble that integration with IFTTT will pay off for the partners. You'd be better off providing and maintaining the integration code, and even paying the partners, until you've established IFTTT integration as a must-have feature for any new service. When Pinboard's customers demand IFTTT integration, you'll have the leverage to push a proprietary API. An even better approach might be to work with your competitors to create an open standard for integration, one that you all benefit from.

You're not addressing the criticism. Don't apologize, change the TOS to make it acceptable.

Why not create an open, public standard, like Atom or RSS?

Sorry but you don't get it.

Reply on news.ycombinator.com