Putting Customers at Risk

I've been thinking more about our long-term responsibility for software bugs and security over the last few months. This weekend the WannaCry ransomeware affecting Windows got me thinking again. Fortunately Ben Thompson just saved me a lot of typing, and said a lot of what I was thinking much better than I could have (also with a much catchier title). Go read this: WannaCry About Business Models.

(I'll wait. You can skip "Spreading the Blame" and "Blame the Government" if you're in a hurry, but I wouldn't.)

The truth is that software — and thus security — is never finished; it makes no sense, then, that payment is a one-time event.

It should be no surprise I'm a fan of the conclusion that SaaS is a good model to combat this, but the reality is not all software works as SaaS. What is our responsibility as professionals shipping software in cases like that? How many years of patches is "enough"?

As a developer, I get it. A customer paid you once up front and it feels unfair to be expected to support them 5 or 10 years down the road with free patches. And largely, I sympathize. But we're luckier than people shipping physical goods in that we can fix our mistakes later. We rely on this as an industry: we don't have to get everything right our of the gate or risk a costly recall and PR nightmare. Because of this, physical goods on a whole ship in much better shape than our digital counterparts.

So I think as part of this privilege of shipping with bugs we need a better commitment to correcting them and doing right by our customers. The often-used attitude of "you need to pay and upgrade from v2.x to v3.x to keep getting fixes going forward" is where things get dangerous. Fragmented codebases caused by different SKUs in an attempt to derive recurring revenue from customers leaves your older customers at risk. And I don't think we as an industry are particularly good at acknowledging that risk and taking responsibility to mitigate it.

Auto manufacturers in the US are required to issue recalls and fix safety issues in cars well after the customer buys the car. I just got one for my car's airbag, and it is 7 years old. Honda can't say "sorry, buy the 2017 model for that fix."

So why can we?

We need to stop with the "upgrade to keep getting fixes" attitude and better accept our responsibility to maintain our software while it is still in use (and we are still in business). If you give customers the option to stay on an old version, for example by relying on paid upgrades, you need to accept responsibility in keeping those old versions maintained1 as long as they remain in the wild. It might feel unfair to be expected to maintain your software for a long time, but that needs to be part of the decision when making a new SKU: you now have two codebases to keep patched. Excluding old releases from fixes, critical to security or not, is just plain user-hostile.

In a world where governments and bad-actors rely more and more on exploits in our work, it is becoming increasingly irresponsible to wipe our hands of our old releases just because we shipped a new one.

There is a whole other conversation about what also came into play here for WannaCry: users not promptly applying the free patches for Win7/8/10 released in March. But getting users to keep up to date with free updates is a whole other can of worms.

  1. "Maintained", for this argument, is security / bug fixes for code which you shipped. If a major OS update breaks your app, eeeehhhh. More of a grey area there.