In my view this has caused yet further reputational harm for Heroku, and is going to have a long-term effect on the bottom line from paid projects. The value prop of Heroku has always been being able to sleep at night, but clearly that's gone now.
In my view this has caused yet further reputational harm for Heroku, and is going to have a long-term effect on the bottom line from paid projects. The value prop of Heroku has always been being able to sleep at night, but clearly that's gone now.
You could easily block all incoming connections to the database. For a free database of 10k rows there were no SLAs, and you would still technically be hosting the database.
Even taking a dump and emailing it to me feels like a safer option here.
There were better answers here for sure. If the honest answer is we just didn't feel the effort was worth it for this class of users at least own that.
Probably not, because it’s ” difficult “
You can pick an arbitrary time frame for retention, but whatever you pick, you have to communicate to users, and you can't just change it on a whim. Normal customers want this clock short. They don't want you to retain their stuff after they cancel.
I highly doubt normal customers want this clock short when the cancellation is not customer initiated.
Thus didn't happen because of the contract, but because the people implementing this transition didn't give a crap.
Silos lead to issues like this. Cross-functional teams cost more, etc.
Onboarding users/partners would be easier without making them read/click all those consent checkboxes, etc.
Ideally, product people defend the end users. Realistically, compliance people defend the company from getting screwed in an audit and ultimately sued by the government.
I had a vague thought for a moment about maybe being able to give customers the option to opt in to an updated set of terms that would've been better designed for the situation ... but since the original Tell HN author didn't get any emails about this at all, presumably they wouldn't've got that one either so even if (and given 'vague thought' I'm not claiming any particular level of 'good idea' to it) that had been done it presumably wouldn't've helped them anyway.
It seems to me the root problem here isn't so much the compliance initiated policies as a complete failure to take 'make sure people have been adequately warned' sufficiently seriously given the potential consequences.
Deeply unfortunate.
(read that last sentence in understated deadpan dry en_UK to get an appropriate read on just how impressed I'm not by the communications cockup)
Why could they not turn it into a read-only database without access from the Heroku apps instead? Then it'd just be a routine change to the service offered, would it not?
I genuinely had to read this twice to get the intended meaning.
i'd probably prefer feces-by-email to surprise database deletion
The company has no commercial interest in doing that, though.
That's hiding behind the T&Cs instead of owning their decision not to even try because there is nothing in it for them.
The T&Cs are an agreement between the parties. That agreement can be changed at any time if both parties agree. So they just need to ask.
Do you really never get e-mails from various companies every few weeks telling you that the terms of service have been updated?
I think I get one from eBay alone every other day.
I can't be the only one who's basically completely blind to emails from major companies, including SaaS providers, because they're so fucking spammy that the SNR is like 1:99. Notifying me by email, for one of these places, is functionally the same as not notifying me at all.
[EDIT] Sorry, didn't mean to imply the parent wasn't paying attention, just that I'd fully expect a very high percentage of their users to miss the warning in all the noise even if they emailed everyone—even if they emailed them a couple times, actually. That's the cost of every company sending out tons of "join our online seminar on [product]!" and "hey, look, it's our newsletter you never read!" and "it's time for our weekly TOS modification!" emails.
This 1000x. I signed up for an SMS gateway service last year. Just for my own hobby use, nothing major. I gave them $10 to start service, and they charge like 2¢ or something per outgoing message.
They have like 180 different prices for 180 countries, territories, provinces, parishes, cantons, prefectures, etc. Every week one of those prices changes, and I get an email notifying me of that. I tried to turn those off in my preferences, but they refused. I can opt out of marketing, weekly digests, and "tips and tricks"; but I can't opt out of pricing notices.
So I added a rule on my end to hide those. I totally understand where they're coming from. They can't NOT give pricing change warnings. But at the same time, in the flood of constant notices, there may be something major I will miss.
It would be nice if they instead gave me the option to never spend more than $0.XX per message, and return an API error if an attempted send fails for price threshold violation. Then the spam wouldn't be needed.
The fact that the failure to send a single warning email to this particular customer wasn't both detected and considered a five alarm fire level bug under the circumstances is the thing that moved the decision to sunset the free tier from sad to disastrous for the user who posted the Tell HN in the first place.
Plus, it would all likely have worked out fine if they'd emailed the customer a warning or three like they intended to do - it was the failure to do so combined with the failure to detect and remediate the initial failure that sent things down such a dark path here.
Whoever fostered that naive interpretation was a nitwit. If they’re an actual lawyer, they promoted an intentional, mutually harmful unilateral reinterpretation of an agreement and should be sacked.
Cowering behind T&Cs like this is intellectual bankruptcy. There’s always another solution. The law is not a programming language.
Contracts with some customers, surely? You could have the default be 90+ days, then those customers whose contracts specify a shorter timeframe get that shorter timeframe configured on their account instead. You could give the customer the choice at signup, and let them change it later using the settings console. If their contract doesn't specify a period, send them a notification that you will be changing it to 90+ days, but telling them they have the right to object if they disagree with that.
Yea, no. You decided to make the decision for contracts to be that way. The fact that you "fought hard" but that decided on the 30 day retention anyways means that clearly the opinions of engineers don't matter and that the company is completely captured by the lawyers and out of touch executives. It hardly inspires confidence.
It also doesn't at all address the fact that you failed to contact an apparently paying customer that their data was about to be nuked, contract or no.
I also assume Salesforce only bought them as a cash generator and has no interest in investing in it. So if they saved bottom line from this move, that's a win for them.
(Feel free to correct my assumptions if I'm very wrong)
Heroku is still quite a bit of value-added over "AWS with some basic CI integration", people chose it and still choose it because it requires a lot lot lot less in-house expertise and management hours than AWS for most kinds of standard apps. (I'm not totally sure what AWS services/architecutres you are thinking of when you say that; but I'll say: for pretty much all of them.)
(Heroku def has more competition in that space than it did 10 years ago, opinions differ on the relative merits)
AWS of course already existed when Heroku was launched, so if you do consider them just "AWS with some CI integration" then I guess they would have been from the start? What would have made that true now if it wasn't then?
I think Salesforce thought it would somehow be more "synergistic" with their other offerings than it has turned out to be. That they'd get Salesforce customers on heroku when they needed something beyond the "no-code" tools Salesforce already provided, or that they'd do better at converting heroku customers to salesforce customers than they have been. It does seem to be true that salesforce stopped really investing in new heroku features or improvements some years ago, and seem to be looking to minimize costs while continuing to collect revenue, I agree. (Sometimes I'm not even sure how much they care about continuing to collect revenue...)
> it requires a lot lot lot less in-house expertise and management hours than AWS
Yeah, you're not wrong there. I do worry though that it's still too complex to really trust someone with no devops bg to be fully responsible for, and at the same time, it's so outmoded (just meaning, it's not that popular now besides for legacy projects) that you aren't going to find a lot of good candidates who are expert with Heroku compared to expert with AWS.
So to me, Heroku is a gamble that you can get by indefinitely with only what you(r existing eng staff) know how to do in Heroku. Which for some projects, maybe that's a decent gamble for the payoff of easier admin in the short term.
> if you do consider them just "AWS with some CI integration" then I guess they would have been from the start? What would have made that true now if it wasn't then?
Yeah good point -- Let's see if I can try to explain my claim better. I think in 2009 using AWS was completely inelegant in every way, it was pretty barebones and basically just "Rent an EC2 server and do whatever you want, good luck." Heroku had a unique (at that time) approach which made cloud hosting much simpler and more abstract. AWS today at least offers a few ways you can host an application on AWS while doing less server maintenance than you'd have needed in '09. Infrastructure As Code is also something I think has a lot of popularity today that wasn't really a thing in 2009, and Heroku if I remember correctly, isn't really about that. So there isn't as much repeatability on that platform, it's more "click around and build your stuff out in the GUI." Which again, is cool in the short term to bootstrap, but can be painful at a bigger scale.
As an early Heroku employee, this gave me quite the chuckle.
Also re the timeline, the acquisition was announced in 2010. So your own usage was already a few years post.
I just imagined Benioff going "Cool, we can buy this and continue to collect the checks every month, while not developing the UI or integrating it in any way into our business." Basically the same thing they did with Exact Target.