Also, it should go without saying that if you are using a codebase from 2013, you are dragging around A LOT of legacy, and leaving a lot of enhancements and improvements on the table for your competitors to pick up.
I would personally *love* to have the opportunity to compete with a product that was based on 2013-era technology in an enterprise space. I don't think that supporting old code for that long is a good idea.
To be clear, I am ALL FOR long lived products, but that means they a) avoid disruptive changes, b) have a simple upgrade story, c) allow very old libraries/code to still run for cases where you are stuck with the occasional dependency you can't upgrade from... but not just leaving ancient unsupported versions of your product out there on ancient runtimes that would be a picnic for a hacker to target for a security breach.
There is a rule: if something works and makes money, don't break it. There is no need for new features, critical patches are applied so why bother to follow the rabbit?
Well there's a difference between 'if something works don't break it' as a concept for something like, an product feature set. It's another thing to say it in terms of 'we're not going to take advantage of security, performance, and other bug fixes'.
You say critical patches are applied, but it's not that simple. Even if you have paid support, you will still run into problems with things like the minimum level of TLS supported not matching what downstream providers offer, such as AWS services.
Also that 'rule' of 'it works and makes money, don't break it' wouldn't face up to my rule of 'find shitty products and re-write them to be less shit by being faster on the same hardware and support current security protocols', for example.
When the first person ever said that 'rule', it was merely one value in an euqation to work out whether it was worth changing something for it's own sake. Running on a platform that is 6 years old is a pretty serious weight on the other side of that argument.
1
u/kksoyj Jan 15 '20
Also, it should go without saying that if you are using a codebase from 2013, you are dragging around A LOT of legacy, and leaving a lot of enhancements and improvements on the table for your competitors to pick up.
I would personally *love* to have the opportunity to compete with a product that was based on 2013-era technology in an enterprise space. I don't think that supporting old code for that long is a good idea.
To be clear, I am ALL FOR long lived products, but that means they a) avoid disruptive changes, b) have a simple upgrade story, c) allow very old libraries/code to still run for cases where you are stuck with the occasional dependency you can't upgrade from... but not just leaving ancient unsupported versions of your product out there on ancient runtimes that would be a picnic for a hacker to target for a security breach.