> 11. Compatibility. Each Licensee Channel must maintain 100% compatibility with the Developer Tool and the Service including changes provided to you by IFTTT, which shall be implemented in each Channel promptly thereafter.
> 17.This Agreement is personal to Licensee and may not be assigned or transferred for any reason [...]. IFTTT expressly reserves the right to assign this Agreement and to delegate any of its obligations hereunder.
Yep. This is bad enough that the simple fact that a site integrates with IFTTT will be sufficient to trigger my brand-new 'Wow. You guys signed that? I am NOT trusting you with data I care about' reflex.
Not saying this is good contract writing, but some relevant context would be what the penalty for breaking these clauses are. If the penalty for not maintaining compatability, as stipulated in the contract, is simply "we turn off IFTTT integration with your app", then that seems reasonable. Ditto for the non-assignment clause.
Now if the penalty is three dogs and a pony, then nuts to that.
IANAL, but in general the penalty for breaking the terms of a contract, in the absence of an explicit damages clause, are whatever business loss the other party suffers as a result.
Any binding agreement between two parties is a contract. There is consideration on both sides: IFTTT is providing access to their dev kit and service, the recipient is implementing an API and providing access to their data. Both sides are, in principle, getting something from the agreement (of course, it's very lopsided and unfavorable to the recipient). Again, IANAL.
If you've never heard of it, If-This-Then-That is a service that lets you connect websites together, so that things that happen in one place automatically trigger some regrettable action someplace else. For example, you might write an IFTTT ‘recipe’ that tweets anything you post on Facebook, because you are a monster.
I'd heard of it (I may have even signed up with it at some point), but this has to be the best explanation of IFTTT I've come across.
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!
> 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.
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.
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.
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.
> 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.
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.
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.
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’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.
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.
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.
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.
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.
> 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.
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?
>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.
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?
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.
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.
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.
But I am all in favor of a 'recipe' that consists of "startup does dumb stuff=>Maciej writes a hilarious takedown=>I LOL so hard people ask me what's going on from two rooms away". Can someone implement the API for that, please?
I hadn't seen Botize before. In structure and capabilities, it looks a lot more promising to me than either IFTTT or Zapier (for instance, it supports maintaining lists and adding/selecting data from them), except that half the site seems to be localized to Spanish and doesn't seem to have an option anywhere to change the site language.
If memory serves that's pretty much how pinboard.in got launched into the air a few years back, so it'd certainly be poetic. Nice of you to pass it on :)
Tried migrating my IFTTT recipes to Zapier and hit a roadblock on the very first one -- bookmarking posts I have saved in Reddit.
Botize apparently has no Reddit integration.
There's a definite opportunity here. I'd even pay more money for Pinboard (on top of the archival fee) for more Pinboard-specific integrations for things like this. It is too convenient.
Thank you! I have RSS feeds set to private by default, so I assumed this wouldn't work. However, I did discover "Private RSS feeds" in the reddit preferences. I can likely feed these into Zapier.
It would be easier to support IFTTT on this if the proposed APIs to be implemented were public. But making the APIs private and then being a dick about it with all the legal threats isn't something that I can reasonably support.
We fully intend to make the APIs public, but are working with existing partners to implement. We are trying to be flexible and understanding, also are not throwing legal threats :)
So you "intent" to eventually make the APIs public but hold your partners to the gun and shut them off if they don't meet all your demands (ToS, new API dev).
What I'm hearing is you want partners to trust your intents but you don't trust any of theirs—as evidenced by the terms of service that is required and binding. The "not throwing legal threats" part comes off very hollow in that context.
If you did trust your partners, you'd make a new API alongside the current setup, and it would be so awesome that people would switch on their own. But as others already pointed out, it seems the value in the new API is self-serving and is inexistent for your partners.
I'm all for collaboration but I suspect you are trying to build a moat around your business and make a ubiquitous platform. I sincerely hope this backfires.
First we strong arm current implementations, forcing them into a Private API that we 'intend' to make public. Sort of how we intend to go to the gym, intend to drink less and intend to think about how our actions affect others in order to be better people this year.
Wait. Why would we believe this statement? Why would the people who willingly implement your private API care about it going public?
This "intend" is as much worth as the intent to build a comprehensive test suite and intent to document the code later.
I was going to integrate my app with IFTTT, but after reading this post, as well as the responses from the CEO in this thread, there is no way I will ever in a million years integrate with IFTTT.
I think its an interesting train-wreck to take note of. And it is clearly a reflection of the CEO, who has consistently misunderstood or ignored the true complaints people have about this new direction, while half-apologizing for terms and blaming "communication" on terms that place absurd expectations on companies that IFTTT chose to integrate with, and now wants to reverse the roles of.
Meanwhile, maciej is doing everything right. Communicating with his users about what is actually going on (instead of lying to them as IFTTT has done), and doing so in a thoughtful and playful piece of writing.
Time will tell how this plays out. But I think if IFTTT's moral compass is willing to let this go public, if they think this is/was an actual good idea, their days are numbered. The PR around this change alone was horribly executed, in addition to the change itself being a big middle finger. Neither speaks to an understanding of their users or sites they depend on to integrate with.
IFTTT would be NOTHING without any other services to integrate with, and they chose to throw them under the bus.
You had a chance, IFTTT. But you revealed your colors, and now you don't.
Really sorry to hear it, but appreciate the feedback. We are working to address concerns across the board regarding ToS and communication. I'd be more than happy to hop on a call to address if you want shoot me an email, my first name at ifttt.com
> 4. Confidentiality
You agree not to disclose (or allow access to) the Developer Tool (or any information derived therefrom) to any third party and will limit access to the Developer Tool (and any derived information) to your employees who are developing your IFTTT channel. In support of this obligation, you will apply at least the same security that you use to protect your own most confidential information.
Did anyone seriously think this through? What about companies that have among their "most confidential information" data, like passwords, crypto keys, confidential memos, etc., that they'd never store on an Internet-connected machine?
Thank you for the recommendations for replacement services. I emailed you about this - and I'm glad you publicly responded, because I smelled something weird in the way the IFTTT email was worded. Very disappointed to hear it was what appears to be pretty shady on their part.
Depending on when the channel was introduced, the backend implementation of a channel can vary wildly. Some were written in Node, others in Ruby, some where written internally, others were written by the service owners.
When IFTTT released the developer platform, they were solving two needs: 1) creating a consistent channel infrastructure, and 2) providing a tool for developers to write channels so they don't have to.
It seems like they are shutting down some of their legacy services, which is probably a good plan for a company with no revenue stream. Not a good plan, however, to make it look like it is the developers' fault.
I went through the IFTTT integration process a while back. I created a platform for indexing street art and made a service that can return nearby street art, when given a lat/lon point.
When I first got contacted about the IFTTT channel, I was excited. After realizing how much of my application endpoint I was going to need to rewrite, it became a task I kept putting on the back burner.
In my mind, the process of integration is being done well. It just requires a lot of lift for individuals who are the only developer on a project that already feels like it has a never ending list of tasks.
Isn't this similar to the shit Twitter pulled on developers?
It's funny - nowadays people don't go along with stupidity like this. They just call the bluff of the business doing the strong arming and drop their support for their platform.
Seriously, if IFTTT want to force people do craploads of work for no real payoff, best of luck to them. I do hope most folks won't play along though. And those license terms? Yeah, best of luck with that. I wouldn't use them either!
I applied to IFTTT about a year ago (didn't get the job), part of the interview process was to develop a channel on their developer platform. I don't consider my self a fast developer but it wasn't difficult and it took me about a weekend of casual work. Maciej is well within his rights to flip IFTTT the bird, but I just wanted to provide some context about how much work is involved.
I agree that implementing a simple API endpoint is easy.
Running that endpoint is not easy. Once it's live, you're dealing with an entangled system of API, user, network, database, server, full moon, voodoo curse, and God knows what else. It's a giant flaming tumbleweed of pain.
Clearly IFTTT agrees, and that's why they're trying to make us do it for them.
You're absolutely right. I will not try to compare what I did to pinboard. I still have the channel running on a DigitalOcean box and even though the service is simple and stable, I still have to fiddle with it once in a while. I only keep it running because it's valuable... to me.
> The developer terms of service don't seem to be available by a public URL, so I will quote the bits that stung me. I invite IFTTT lawyers to send me a takedown notice, because that will be the funniest part of this fracas so far.
Fun fact: legal language is not protected by copyright and can be copied, modified, republished, or reused.
> Fun fact: legal language is not protected by copyright
With respect: are you a lawyer?
I'm not, but all the sources I can find written by actual lawyers put this claim somewhere between 'wildly oversimplified' and 'false', depending on jurisdiction and the kind of legal language (contracts vs legislation, etc.).
Eg for US law, [0] quotes Nimmer on Copyrights § 2.18[E] as stating that ‘There appear to be no valid grounds why legal forms such as contracts, insurance policies, pleadings and other legal documents should not be protected under the law of copyright.’
I am not, but I have been previously advised on this topic by lawyers who specialize in IP.
Of course, your mileage may vary and my comments on the Internet should not be construed as legal advice for your specific situation.
Edit to add: The advice I received was in the context of contracts, privacy policies, and terms of service. I don't know about, and didn't mean to include, legal language in legislation or court filings. Important clarification--thanks.
I'd spend money on a Yahoo Pipes + IFTTT solution with some kind of guarantee they're not going to vanish overnight. You know, like a Pinboard.in style company. I think we need to clone Maciej.
If all those services provide JSON blobs, that's halfway to making an RSS feed of them or building a custom search interface or what have you. The other half is standardizing common field names (so you don't have the same field named "created" or "published" or "date" depending on the source); Dublin Core and the like take care of that.
This is kind of an idea a coworker and I have been toying with. At it's core, all you really need is a pub-sub server, with daemons publishing and consuming some JSON blobs. Redis is a pub-sub server out of the box, write some simple Python wrappers that poll web pages, RSS feeds, etc. and publish, and on subscribes perform actions (i.e. hit the API!)
I would like to convert a script I have which polls from my Gmail for credit card charge notifications and publishes to Airtable (which works great for this task!) to a more-general Gmail listener which publishes, and a more-general Airtable publisher which can be setup to record certain messages.
We have such a system already, it's called PubSubHubbub. It's an open protocol, and there are already multiple servers (paid and free) and support by software, both by publishing systems like Wordpress and by news readers.
I have to admit I use IFTTT to take an RSS feed from our kid's elementary school and post the entries to a Facebook Fan Page. The idea being to avoid having to teach my wife to use an RSS reader, now she (and another hundred or so people) get the school news without leaving Facebook.
I feel conflicted in some ways but pragmatism wins. Anyone know a non-IFTTT way to set this up?
You are using very strong words to describe a very weak signal, and it comes out sounding like noise.
Self-respecting programmers make lots of good and bad decisions, and trying to exclude someone from that category because they went down a particular path is divisive and unproductive.
If you had said, "I don't see why one would opt to use a service rather than write a script for this very simple task," you might've gotten an interesting answer pointing out something you missed.
No self respecting programmer would throw away the chance to learn a valuable lesson to grandstand.
(Edit: Though I've totally made that mistake before.)
You write your little glue code, then you spin up a server to run it periodically (which costs money), then you're forever on the hook for patching, restarting, adding features, dealing with api changes, etc etc etc...
As opposed to "set up, forget about it, have a beer".
You're right, I did have that on my mind when I was posting and was hoping not to catch too much flak! Someone down the thread mentioned keeping things running, debugging, etc. which is part of what kept me from doing it on my own as I have enough small side projects to debug without adding another.
It really began as me trying to find an exercise in seeing what the easiest way to inform someone who is always checking a specific app already, and I had heard of IFTTT but hadn't checked it out or put it to use myself. I think it's interesting that IFTTT has been successful since it seems like the demographic who would think to convert an RSS feed to Facebook posts (and not code it themselves) would be fairly small.
Anyways, setting it up with IFTTT took me less than 15 minutes and has never given me any problems, except when the auth expired (triggering an email from IFTTT) and I had to reauthorize the integration with Facebook. I wonder if I would have had the foresight to set up email notifications with my homegrown solution?
The problem is not the 10 line script. The problem is maintaining it. Adapt it whenever something changes, preferably before it breaks. Keep it running on some server. Monitor that.
IFTTT has acted throughout as if they were doing Maciej a favor by letting him implement their API, which makes no sense at all. But! According to zacwest[1], the access they're offering him to their "platform" costs $3000 if you walk in off the street.
So not only are they trying to get people to do IFTTT's work for them, they're trying to get people to pay for the privilege of doing IFTTT's work for them. I'm, er, impressed.
I want to make a correction about the patent bit. Maciej says:
> And they assert the right to patent any clever ideas I have while doing that free work for them, even though I hate software patents:
The relevant bit of the IFTTT TOS:
> 12. Patent License. Licensee hereby grants IFTTT a nonexclusive, sublicensable, perpetual, fully-paid, worldwide license to fully exercise and exploit all patent rights with respect to improvements or extensions created by or for Licensee to the API
They're not trying to patent your work, they're saying that you grant them a license to any patents you might get that relate to your IFTTT integration. In other words, a developer cannot create an integration for IFTTT, patent something in there, then turn around and sue IFTTT for patent infringement. This is pretty standard language in software licenses/contracts/terms of service.
Can someone elaborate more on the "Working for Free" section? I'm not well versed in IFTTT, but shouldn't I as the owner of a website that wants to offer a recipe be responsible for the details that recipe? This is all very unclear without specific examples.
The site doesn't provide recipes, it provides endpoints (API calls) that users can write recipes to use.
How it worked until now:
1) IFTTT wrote glue code to interface with a site's published API, and IFTTT could then write recipes to use the site. IFTTT thus stitched together other sites published APIs as a service.
How IFTTT has decided it will work from now on:
1) IFTTT comes to you and orders you to write private endpoint(s) that do X, Y, and Z. They reserve the right to ask for additional endpoints, different call results, or anything else they dream up down the road. You sign a legal agreement promising to ask "how high?" any time they say "jump". You will not be compensated for this privilege.
Wouldn't you be performing this work because you believe it will facilitate the transfer of traffic to your site? Aren't you comitting to make changes as and when ifttt change their API so that you can continue to receive their calls? Sites/services can just walk away if they don't want the traffic. No one's obliged to pay or do anything they don't want to.
I think the subtlety that's not evident from these comments is that Maciej didn't solicit IFTTT integration to begin with. In fact, as I recall it, IFTTT did a hacky integration that misused Pinboard's authentication, and Maciej had to help them correct that.
Later, after putting a bizarre legal agreement in front of him to sign, IFTTT announced that Pinboard would stop working on their service in a manner that made it sound an awful lot like Maciej had just decided to stop supporting IFTTT. In reality, all the agency in this relationship belonged to IFTTT.
I should clarify that the terms of service I quoted are a thing you agree to by using their developer site, and that I was not given a document to sign.
If they actually succeed at that, it's gonna be a laughing season. Every time a company does something and becomes widely successful, their methods are then recommended on business trainings, startup conferences, etc. So if IFTTT actually manages to subdue many services this way, you can expect other startups to think they can build business out of a) hooking up to your service without your knowledge, and b) telling you you're supposed to become their customer now.
Isn't that the Yelp business model? They're notorious for calling up businesses (mainly restaurants) and then offering the business a way to pay to remove negative comments on Yelp (there was a case where some were entered by a Yelp employee!)
It's essentially the "protection/promotion" model.
Its a fairly well known accusation that has many pieces of circumstantial evidence as well as many lawsuits.
Many business owners have claimed yelp salespeople have called them and tried to sell them the ability to bring down unfavorable reviews or that they would highlight them.
> “[T]he business owners did not allege sufficient facts to support their claim that Yelp authored negative user reviews of their businesses.”
The ruling was that if yelp manipulated ratings, that's fine, but there's no evidence they did. I don't know whether to believe they've done it or not. There's a lot of business owners over the years who report having gotten shady calls, but it'd be really hard to prove those calls are from yelp and not from fly-by-night scammers. I get calls from "Cardholder Services" and "Microsoft" pretty regularly, so it shouldn't be surprising if there are extortive yelp scammers.
> Wouldn't you be performing this work because you believe it will facilitate the transfer of traffic to your site?
That is surely how IFTTT will pitch it to 3rd parties... but, really, probably not. Being accessible in the Recipe list isn't great advertising, anyone not using your site already probably isn't going to sign up due to seeing your name on IFTTT.
Framed another way, there is a famous saying in the design industry: "I can't pay you, but it would be great for your portfolio". Classic exploitation tactic; manipulative and predatory.
Part of the point is that IFTTT has a fully working connector today, and is just going to turn it off in a few days' time if Maciej doesn't sign this new agreement. And Is then sending emails to his customers laying the blame at his feet.
It is correct in the sense that they're not forcing anyone to use IFTTT, but they make it sound like the website owner is responsible for the degradation of service, while in reality it's IFTTT's decision.
Yeah, but i'm not getting how they're doing anything wrong. It's their site/service; they can make any changes they want. It's like developers having to keep up with changes to Android, for example. The UI can change from release to release; new rules get added to the play store; how access to external storage is allowed/handled changes often. Google isn't doing it for the fun of it and it makes no sense to take them to task over it; it's just one of those "keep up" things which has been at the root of software development for as long as I can remember.
Nobody is arguing that IFTTT can't change their service as they see fit. They can, as they've chosen to here, move from a model in which they write client code for other sites APIs, to a model where other sites write client code for their API. It's obviously beneficial to IFTTT if they can offload this work to other sites for free.
What's shitty and rude and presumptuous about their behaviour is going to other sites who never asked to be part of IFTTT (IFTTT was just a consumer of pinboard's public API) and saying "here sign this and get cracking on implementing our specs".
And when a site owner refuses such a "request", IFTTT is basically lying to its customers when it says that Pinboard has chosen to leave the service, rather than "IFTTT has chosen to shut down their working pinboard API client code".
To reuse your analogy, it's as though Google themselves built an App client for my site, then decided to move to a model where Android apps were responsible for hosting and bandwidth of their own app (their right) and disable all apps in the store who didn't specify a hosting location (their right), deleted the app they built (their right), mailed me the specs for their app and a deadline to reimplement it myself and host it at my cost (why would I be interested in this? I never asked for any of this), and then when I told them to get bent emailed customers "Sadly, beloved app $APP has chosen to take themselves out of the Android store" (lying).
Keeping up with something you chose to support (like if you wrote an Android app) is reasonable. But that is the opposite of what happened here. IFTTT chose to support pinboard, not the other way around. If they are choosing to stop support, they need to own up to it, not put the blame on IFTTT.
I believe, and I could be wrong here, that previously IFTTT simply consumed public APIs to cobble things together. They are now asking services that want to be IFTTT-able to expose an API that IFTTT defines. IFTTT will still be hitting endpoints on the developer's product's site, but the endpoints are defined by IFTTT and not public.
This isn't about offering recipes, this is about IFTTT requiring sites to write support for a new API (notice, it's not write to a new API, they have to build this new PI in to their site) so others can write IFTTT recipes.
> I am all for glue services, big and small. But it's better for the web that they connect to stable, documented, public APIs, rather than custom private ones.
This is the clincher for me. I spent about 15 minutes looking around IFTTT before figuring out that there were no developer docs because this is a service for enterprise customers, not for us.
Big companies might get away with toll booths - how about small ones like IFTTT? There are alternatives, these services are not absolutely necessary (like payment processing or hosting) etc etc. It is in their own interest not to screw people over. There will always be someone else to take their place.
Some other people are saying they've seen Chrome complain, but I can't reproduce it. Please send email (support@pinboard.in) if you can figure out what's up.
Cert chain is incorrect basically and the browser is fetching intermediate certs to try to make it work.
Most of the issues Qualys points out on blog.pinboard.in are not present on pinboard.in itself, so I presume there's a difference in config there that would be a good place to start. They're also running on different versions of Debian (squeeze v. wheezy, which ship different OpenSSLs) which accounts for some of the variance.
Also, as Qualys notes, disable RC4 ciphers on pinboard.in and you're in pretty good shape.
HN meta: I'm sort of disappointed that this has been getting downvoted.
Obviously, what Linden is saying in this case is probably not helping his business case. It's clear to me that he either does not understand why Maciej doesn't want to implement a private API, or does not wish to understand it.
On the other hand, neither of those things are grounds for a downvote, I think. A downvote says "this content shouldn't be on HN" -- that there's something about a comment that detracts from how the community operates. Linden has been completely respectful in what he says and how he says it. Maybe that's not the case in what he's asking his users to do, but we may as well let him ask.
Ehh, I'm not sure that's generally accepted. A few years back pg himself did say downvotes could be used for showing simple disagreement, and many people seem to agree even today.
If people use downvotes to show disagreement, than HN is sunk. No-one likes downvotes, and it will create a community where people only post those comments that they think everyone will agree with.
Instead, downvotes should only be sed to highlight comments that should never have been made.
Dude, that ship sailed some time ago. And I say this as someone who agrees with the HN "mob" on most things. The hardcore libertarian-randist opinions you'd see relatively often around here have all but disappeared.
It's the signals destroying trust that create the animosity, and will tend to make it harder to have decent, respectful, working relationships with integration partners. It reads as lopsided and occurring unilaterally, without any degree of trust or respect for said partners.
A startup becomes uncool when it starts driving code churn as a value reducer ostensibly as "new value," but instead alienates their vendors and customers alike. IFTTT reminds me of the audicity of Hillary Clinton assuming she's already the next president while avoiding releasing those damaging Goldman Sachs transcripts (where her boilerplate contracts require a stenographer, and an attendee describes the tone of one speeches as that of her acting like a managing director cheerleading the troops). Or maybe the Drumpf's endless list of bankrupt companies and bringing meat from the grocery store to prove nothing. Oops. Edit: Anyhow, I'll move my weather warning texts over to a service that doesn't molest its developer partners without their consent. Thanks IFTTT, here's your mixtapes back.
Isn't much of the legal stuff just a way to cover their tails?
For example, the bit about owning content. Do they really want your content? Is content on the internet worth anything these days? If your content is worth something, it's likely the Google ranking which gives it value rather than the content itself.
I imagine that's just an attempt to keep people from suing over reproducing content to go over the pipes.
PEDRAGOSA V. GOOGLE SPAIN, S.L. - Google got sued for reproducing content in various ways in search results. The case went in Google's favor but the legal costs for this sort of thing is probably a killer for services which don't have that GOOG ticker symbol.
The "no competition" bit seems like it's meant to keep people from using IFTTT developer tools as part of their own competing service.
Why bother reading the legal stuff? It likely won't ever come up to affect you. There is some risk, but the opportunity cost of taking the time to go through it is probably greater. I imagine most of the world population doesn't have the comprehension ability to understand what they are reading anyways. You might as well just stop using the internet rather than trying to make sense of the legal stuff.
> Isn't much of the legal stuff just a way to cover their tails?
Sure, but most of it puts your tail on the line instead. They've decided that they somehow have enough power to make you do their job, and make sure you do it in a way that protects their legal interests over yours. You'd be a fool to agree to it.
> Do they really want your content?
Yes. Their lawyer told them that it was a good idea to make sure their license agreement gave them (and I quote) all right, title, and interest (section 3) to any materials displayed or performed on the Service (definition of "Content" in section 1). They thought it was a good idea to follow said lawyers advice, because it was easier for them if they could just do whatever they wanted with your content. So, yes, they want it. That's probably not because they want to run off with it, but because it's easier (for them) that way and they don't care about you. It's much easier for a business to evolve and grow when they know that they can just do whatever they feel like and don't have to stick within the narrow terms of an existing agreement. Open "give me all your stuff" agreements are much simpler to use.
> Why bother reading the legal stuff?
Because they could be bothered writing it, so they obviously think it's important. And it gives them all the rights that they could possibly want for nothing in return.
If it's not important, then it didn't need to exist in the first place. If it needs to exist, then it's worth reading.
We're not talking about a simple end-user here, this is Maciej's company and full time job, and IFTTT seems to want to use this license for B2B integrations. Crazy!
There are lawyers who write contracts that the other side will agree with.
Then there are lawyers who write contracts to see what the other side will stupidly agree to. (And bill additional hours for all the rewrite they need to do.)
You can choose either kind of lawyer for your business, but be aware that the people with whom you do business will judge you for it.
I feel like there are two sides you can take on this. There is the "ideal" side where we read all the fine print and stay away from services which violate X elements which we individually consider as going over the line. Then there is the boots on the ground reality which is what really happens vs. what could happen.
I don't think either side is right or wrong. I see people like RMS as being on the extreme end of the ideal side. He may be right. His tech usage habits from his beliefs may work for him. But I'm not willing to go that far.
I think leverage may be a silent force in this case. If X service has terms I hate but I feel like I really need the traffic I can generate from that service (so that I can eat) then I'm probably going to jump on it. If I feel like I don't need the service, then I may not bother. I may complain about the terms, but being unwilling to put in the effort for something I feel I don't need might be the greatest force.
In the Philippines, all businesses are on Facebook because Facebook is the internet. Facebook plays similar games with their terms (as does a long list of services). But if you want to advertise to locals, you don't have much choice but to give in.
I would like to see someone who is expert in this area weigh in on why these services come up with these terms. IFTTT isn't going to be selling or using user generated content. I don't see that Pinboard has any content to lose of their own (all of their content is user generated?)
I'm sure I'm wrong, but the only reason I can come up with is to cover your ass if someone sues you for content which goes through your wires and potentially gets displayed on your site. Covering your ass isn't evil. Attempting to remove the right for one side to sue in the normal operation of the service is attempting to create a lopsided relationship (one side gains powers while the other side loses powers.) But they may be necessary for a service which has received funding and could be a target for court battles.
I don't agree with much of your logic.
> If it's not important, then it didn't need to exist in the first place. If it needs to exist, then it's worth reading.
I have a spam folder in my email which I would submit as evidence to refute this point. I could also submit my Facebook feed, Twitter feed and a whole bunch of other sources.
> I would like to see someone who is expert in this area weigh in on why these services come up with these terms
Obligatory IANAL. But I don't need to be.
IFTTT came up with these terms because they believe the terms to be beneficial to them. It's that simple.
They could have put terms in which said "integration with IFTTT means you're giving us permission to connect to your service, and to copy and redistribute the data without limit". After all, that's what they do, technically.
Instead, they're claiming ownership over the data. Your data.
> 17.This Agreement is personal to Licensee and may not be assigned or transferred for any reason [...]. IFTTT expressly reserves the right to assign this Agreement and to delegate any of its obligations hereunder.
Any developer signing this agreement is nuts.