8 ms·

> Indiegogo, GoFundMe, npm, Musical.ly, TaskRabbit, Meetup, OLX, ThredUp, YouNow, 99 Designs, Carousell, and Zendesk Half an hour of warning, to screw over all

• jquery 8y ago
  More companies than that, and large ones. These are just the ones that went public... some of them don't want you to know their trust/safety/moderation features just went dark. Smyte just ruined a lot of people's day(s).
  • TheSpiceIsLife 8y ago
    Twitter. Twitter just ruined a lot of people’s days.
    • chris_wot 8y ago
      Twitter has ruined a lot of people's days for a long time now. Especially in the Trump era. Nothing new here!
      • workinthehead 8y ago
        Not sure why you are being downvoted since Twitter has a well-established history of pulling the rug out from under people who depend on it.
      • deleted 8y ago
        [deleted]
    • kentonv 8y ago
      No. Smyte had a responsibility to its customers, and should not have entered into any deal that did not include some reasonable wind-down plan.
      • TheSpiceIsLife 8y ago
        Have we read the contract? Do we know what happened?
      • PurpleBoxDragon 8y ago
        What about blaming the companies who decided to depend upon a service that they have no control over? I find arguing against using third party APIs to save a few days of development a constantly losing battle, with it being presented as a benefit with no costs or risks. Do those pushing/agreeing with such a view not share some blame?
        • Bartweiss 8y ago
          > that they have no control over Per the article, they did at least have long-term contracts locked in with Smyte. That's not the same as control over the feature, obviously, but plenty of companies do business on the strength of contracts instead of vertically integrating their entire product. Obviously we don't have many details yet, but I think there's a real difference between simply using a third party API that works for the moment, and buying a service from a third party. If Twitter/Smyte simply broke contract with all their existing customers, that's very much their responsibility.
        • brazzledazzle 8y ago
          This isn’t really a leftpad issue. This was for fraud prevention.
        • paranoidrobot 8y ago
          > What about blaming the companies who decided to depend upon a service that they have no control over? Unless you're advocating against any kind of *aaS, this is kind of a silly argument. A lot of these services are not "a few days of development" worth of work. The value in these is that they have dedicated teams of people who's entire job is to run that specific targeted thing. Unless you're willing to also invest in major development, it's going to be difficult to match that functionality. Obviously when you make your product/company depend upon these things, you're taking a risk that they could go away, but you protect yourself against that by having robust contracts. Outages are different, but for a significant outage you expect to see some kind of RFO and explanation of how they're going to mitigate it. Deliberately withdrawing service for all customers with 30 minutes notice? That's entirely the fault of whomever is in charge at Smyte. Even 30 days, while it'd probably ruin some existing plans, would at least allow people to have a chance to migrate without things just breaking.
• murukesh_s 8y ago
  It's worse for companies that have shipped mobile apps with the API embedded in the client. Web apps can at least try an alternative or disable the affected features until they work around this mess..
  • maxxxxx 8y ago
    This confirms my belief that I don't want to ship anything that uses directly a third party API. Instead always go through your own server which then calls the API so at least you have a chance to replace that.
    • cinquemb 8y ago
      When I was developing mobile apps, this is what we did. Too many times something changes and trying to update the code in the mobile app is way more of a pain than updating the server.
    • chatmasta 8y ago
      That works for a lot of cases, but for many tracking APIs you want the request to come from the end user, so the tracking service can get their IP and network metadata. That would certainly apply to a fraud detection API. Tbh that has always frustrated me though. I should be able to pipe those requests and just add an X-Forwarded-For header.
      • nmg 8y ago
        This is not my area of experience, but is it feasible to capture all raw tracking data from the client devices and then just pass it on to the API?
        • jdironman 8y ago
          That's basically a proxy or MITM, no?
          • 8y ago
• pkaye 8y ago
  What would be these businesses backup plans if Smyte went bankrupt instead being acquired?
  • shakna 8y ago
    Presumably you would get more than half an hour to migrate.
  • JauntyHatAngle 8y ago
    A company going bankrupt usually doesn't give 30 minutes warning that they are shutting down services though. They give more warning than that.
  • tinus_hn 8y ago
    Your supplier going bankrupt is a well known risk that you cover by checking its credit rating and by paying on or after delivery.
    • sverhagen 8y ago
      That's why often startups can't do business with big companies that hold to rules like that. Would Smyte's rating have cut it for people?
    • fauigerzigerk 8y ago
      Your supplier getting acquired is also a well known risk that you cover by reading/negotiating the contract. The problem is, if all suppliers use the same contract clauses you may not have a choice.
    • AznHisoka 8y ago
      How do you check the credit rating of a startup? and how would their credit rating be affected if they pay all their bills but just reduce the number of bills gradually over time?
      • PeterisP 8y ago
        One way that's sometimes done is that you require them to submit an independent respectable audit of their financials, or in case of confidentiality issues, not submit the actual financials but a statement from a respectable auditor that they have verified the suppliers financials and their cashflow/"runway"/etc satisfies the criteria that you required.
• snowwolf 8y ago
  I'm not denying that what they've done is really bad, but who puts a 3rd party API in a critical path without having any fallback (alternative service, reasonable timeouts, etc.) for when it goes down (as almost any service will eventually do)?
  • striking 8y ago
    People who have multi-year contracts with those API providers, probably with an SLA detailed in the contract. Especially since this API call would have to be on the critical path; you don't want people signing up when the anti-spam service isn't running.
    • snowwolf 8y ago
      1. You have an SLA guaranteeing 100% uptime? 2. If it's that critical, you have redundancy (an alternative provider, or a naive implementation that maybe causes more false positives but that will cover you during an outage)
      • striking 8y ago
        No, but if I were npm, I'd have an SLA guaranteeing three-and-a-half or four nines of uptime (which is far from unreasonable) and just accept that there might be times that signup is not accessible because that'd only cost me a couple hours of signups a year. And no, I wouldn't have an alternative provider. It would not make sense to, if I'm paying a company to provide a service. Why should I pay another to do nothing?
      • hluska 8y ago
        I might be wrong, but I'm getting the sense that you don't have much actual experience. I've been a senior developer in an organization and known that a solution isn't perfectly robust. Clearly I want to fix it because I (like most other developers) like building robust solutions, but I have six weeks of tasks to finish in two weeks, and that isn't one of them. What do I do? You might say "do it anyways" and, if so, that's a junior developer attitude. I'd strongly urge you not to do that as shipping big projects is really more about choreography than engineering. Or, you might say "fight for permission" and that's not a bad idea, as long as you accept that you'll likely lose. You'll likely lose for business reasons. On some level, we all know that a SAAS on a critical path is a bad idea, but we do math. Our SLAs are not 100%, but we can accept a few hours of downtime a year. And, the probability of a service you've seemingly vetted being acquired and shutting down this quickly is low. Is the probability of a shut down like this high enough to justify adding and testing redundancy? The math usually works out in favour of bug fixes and new features > redundancy.
• Bartweiss 8y ago
  > Clients had multi-year contracts in some cases. I wonder how much Twitter is going to pay on top of the acquisition cost of what I can only imagine constitutes breach of contract with all of these companies. (If it doesn't, why even bother having a contract with a duration?)
  • hodgesrm 8y ago
    Kind of depends on the terms of the deal, namely whether it's an asset deal as opposed to a stock deal. In the latter Twitter would assume liability for contracts. In the former they just acquire IP and hire away the employees. Acquirers usually prefer asset deals for this reason as it allows them to leave unpleasant liabilities behind. There's generally some sort of shell left that goes through wind down but it has few/no assets attached. In this case you can try to go after the original investors including founders or other shareholders (the IRS may do this if there tax issues) but since there's nobody home you are less likely to get much out of a favorable judgement.
    • heavenlyhash 8y ago
      This seems like the kind of thing a legal system should be designed to help defend the market against. It's a net negative to the economy as a whole to let torpedoes like this fly without consequence; and evidently, a totally Laissez-faire market will engineer ways to insulate the perpetrators against the damages rather than the insulate economy as a whole against the splash.
      • hodgesrm 8y ago
        On the flip side asset deals also let acquisitions proceed that would otherwise be blocked due to uncertainty about liability, which is another way of saying that the acquirer can't properly assess value of the investment. I have been through this process and have some experience with the type of issues that can arise--in our case they had nothing to do with screwing customers. It's possible Smyte would have just disappeared anyway. Moreover recovering damages in this kind of case is time-consuming, doubtful, and too late to fix anything. (Like closing the door after the horse is gone.) What's left is reputation--the names of the founders of Smyte are listed at https://www.crunchbase.com/organization/smyte https://www.crunchbase.com/organization/smyte. I would have some pretty hard questions if they ever showed up in a deal or looking for work. p.s., According to the Techcrunch page "Smyte stops bad actors on marketplaces and social networks." You can't make this stuff up.