5 ms·

As someone that has been running a free API for coming up to 5 years now, I really don't think you handled the shut down very well. I understand you were offer

As someone that has been running a free API for coming up to 5 years now, I really don't think you handled the shut down very well. I understand you were offering a free service, but nowhere on your site did you ever mention it was an "experiment" and that you might shut it down at any time. If that was the goal, I think it's only fair to give your potential users notice. Is it a smart idea to build anything on a free service? No, but this services as a prime example of why not to. I think we need to be a bit more responsible with how we handle these shut downs. If you have a heavily used (180 million requests per day!), free, public service, you should really plan around slowly decommissioning it, rather than a two weeks heads up before an abrupt hard shutdown. I feel for the guys who had to come up with a quick patch for the set top boxes. They most likely had nothing to do with implementing your API, but now there are thousands of customers who's set top boxes are crashing because you were unwilling to work something out with them. It's not your fault, but it's not their customers fault either. In this case, minimal work on your part would have given them the chance to patch and push a firmware update out. I'm not sure what really happened, but from what you wrote it didn't sound like you really gave them any options, which seems pretty irresponsible.

lotyrin 11y ago
Their set top boxes were crashing because they couldn't handle an error code properly, any other position is untenable. These same set top boxes should have also crashed in the case that a connection timed out or the service was temporarily unreachable. You don't make a call to a service over the internet (whether you're paying for that service or not, whether it's your own service or not) without handling the case where it didn't succeed. There is no such thing as 100% uptime for a service (or a link between you and a service) and not defending against failure here is just tempting the fate that they ultimately suffered. I do not sympathise with them in the least. And that's disregarding the error of having SLA expectations for a service where you don't have an SLA because you are not a customer.
- stanmancan 11y ago
  I never disagreed with that. I agree that not only was their implementation of the API unwise, but it was done incorrectly. However, with that being said and done, the author had a choice to either help find a temporary solution, or leave them high and dry. He opted for the later, and that's the part I disagree with. It wasn't his fault, but he had a chance to make a significant impact for fellow developers (who probably did not implement the API), and more importantly a ton of unsuspecting people at home, and chose not to.
  - dpark 11y ago
    I don't know why he didn't offer to host it for the two-week period in exchange for reimbursement for the cost of running the service, or cost+20% if he wasn't feeling charitable. That seems like the obvious mutually-beneficial solution. And if they turned him down, then it's purely on them at that point.
    - donatj 11y ago
      This. This is what I would have done. I get a lot of emails with special requests along these lines. I used to do the simple ones for free and just ignore the larger ones, but my dear friend told me just tell them your hourly rate. It turns away the non serious and keeps the ones that really need it, and either way benefits you.
    - rdancer 11y ago
      I speculate that after a week-end of nightmare, he was just happy to have implemented a solution that offloaded those trillions of requests onto GitHub, has put it behind him, and was not quite eager to make it his problem again.
coderjames 11y ago
You want the author to do more than just minimal work. The minimal work was the two weeks notice. "I stopped the service as planned, on November 15th, after a two weeks notice." They had a chance to patch and didn't take advantage of it. If a company is using an external business-critical API and isn't bothering to pay enough attention to it that they see and respond to a two week shutdown notice, nothing is going to make them transition except a hard shutdown. And the service provider's request, to redirect the author's domain to their own endpoint, is obviously a non-starter. Maybe they could have offered to pay the growing hosting bills instead.
- stanmancan 11y ago
  > They had a chance to patch and didn't take advantage of it. Did they though? From what I can tell, the author never required users to 'sign up' for the API, he simply said here's the end point, here's the format, go at it. That means he is/was unable to reach out directly and notify his users via email. He's relying on them visiting the website on a daily/weekly basis just in case something changes. I don't think that's a very fair expectation to have out of anyone.
  - st3v3r 11y ago
    I think that's a pretty big red flag for anyone using the API to think that maybe they should prepare for this thing to go down at any moment.
  - dpark 11y ago
    > he simply said here's the end point, here's the format, go at it. I think this is the real lesson. Don't encourage people to take dependencies on you without requiring they give you a way to contact them. Another lesson here is the value of the "scream test". If he'd turned off the service for a 24-hour period, it would have been enough to get most people's attention. This is doubly-true if he returned the 403 with a body that stated when the hard cutoff was.
  - detaro 11y ago
    What would you suggest would have been fair in this case?

lotyrin 11y ago

Their set top boxes were crashing because they couldn't handle an error code properly, any other position is untenable. These same set top boxes should have also crashed in the case that a connection timed out or the service was temporarily unreachable. You don't make a call to a service over the internet (whether you're paying for that service or not, whether it's your own service or not) without handling the case where it didn't succeed. There is no such thing as 100% uptime for a service (or a link between you and a service) and not defending against failure here is just tempting the fate that they ultimately suffered. I do not sympathise with them in the least. And that's disregarding the error of having SLA expectations for a service where you don't have an SLA because you are not a customer.

stanmancan 11y ago
I never disagreed with that. I agree that not only was their implementation of the API unwise, but it was done incorrectly. However, with that being said and done, the author had a choice to either help find a temporary solution, or leave them high and dry. He opted for the later, and that's the part I disagree with. It wasn't his fault, but he had a chance to make a significant impact for fellow developers (who probably did not implement the API), and more importantly a ton of unsuspecting people at home, and chose not to.
- dpark 11y ago
  I don't know why he didn't offer to host it for the two-week period in exchange for reimbursement for the cost of running the service, or cost+20% if he wasn't feeling charitable. That seems like the obvious mutually-beneficial solution. And if they turned him down, then it's purely on them at that point.
  - donatj 11y ago
    This. This is what I would have done. I get a lot of emails with special requests along these lines. I used to do the simple ones for free and just ignore the larger ones, but my dear friend told me just tell them your hourly rate. It turns away the non serious and keeps the ones that really need it, and either way benefits you.
  - rdancer 11y ago
    I speculate that after a week-end of nightmare, he was just happy to have implemented a solution that offloaded those trillions of requests onto GitHub, has put it behind him, and was not quite eager to make it his problem again.

coderjames 11y ago

You want the author to do more than just minimal work. The minimal work was the two weeks notice. "I stopped the service as planned, on November 15th, after a two weeks notice." They had a chance to patch and didn't take advantage of it. If a company is using an external business-critical API and isn't bothering to pay enough attention to it that they see and respond to a two week shutdown notice, nothing is going to make them transition except a hard shutdown. And the service provider's request, to redirect the author's domain to their own endpoint, is obviously a non-starter. Maybe they could have offered to pay the growing hosting bills instead.

stanmancan 11y ago
> They had a chance to patch and didn't take advantage of it. Did they though? From what I can tell, the author never required users to 'sign up' for the API, he simply said here's the end point, here's the format, go at it. That means he is/was unable to reach out directly and notify his users via email. He's relying on them visiting the website on a daily/weekly basis just in case something changes. I don't think that's a very fair expectation to have out of anyone.
- st3v3r 11y ago
  I think that's a pretty big red flag for anyone using the API to think that maybe they should prepare for this thing to go down at any moment.
- dpark 11y ago
  > he simply said here's the end point, here's the format, go at it. I think this is the real lesson. Don't encourage people to take dependencies on you without requiring they give you a way to contact them. Another lesson here is the value of the "scream test". If he'd turned off the service for a 24-hour period, it would have been enough to get most people's attention. This is doubly-true if he returned the 403 with a body that stated when the hard cutoff was.
- detaro 11y ago
  What would you suggest would have been fair in this case?