3 ms·

True, but I think the "continous deathmarch treadmill" is the real problem, well above any license changes.

falcor84 3y ago
It seems to me that a big reason for this is the rapid pace of exploit developments. Every system-level tool has to be able to quickly adapt to deal with those security issues, either in its own code or in its dependencies, and these of course bubble up the stack, such that you have to keep updating to protect your users. And these updates somewhat regularly force (or make it difficult to avoid) breaking compatibility. So if you're breaking compatibility in small ways, that makes is easier to say "well let me just make these bigger changes, while I'm already here". And of course there's also the competitive aspects of featuritis. And this then causes the "Red Queen's race"[0], similarly to animal evolution, where if you don't adapt to the ecosystem, you go extinct. [0] https://en.wikipedia.org/wiki/Red_Queen%27s_race https://en.wikipedia.org/wiki/Red_Queen%27s_race
- jtc331 3y ago
  I think the bigger reason is simply that backwards compatibility is hard. Some projects put in that work (e.g., PostgreSQL), but it comes at a significant tax on productivity that could otherwise be put into new features.
  - jjav 3y ago
    > I think the bigger reason is simply that backwards compatibility is hard. Backward compatibility requires some care, but it's not exactly hard. Simply don't change interfaces or exposed behavior. You can always add new APIs, just don't break the current ones. The only time it is hard is when there is a security vulnerability that is difficult to fix without breaking compatibility. But that's not very often. I came of age in the culture of never, ever breaking compatibility. You'd get raked over the coals in design meetings for ever voicing such forbidden thoughts. It's a wonderful approach because everything just keeps working. As it should be. The software industry needs to grow up to what it used to be.
  - hinkley 3y ago
    When you don't put in that work you're externalizing it onto others.
- fouc 3y ago
  I think it should depend on the attack surface - is the software on a server that is exposed to the public? If it's relegated to private servers then it is easier to secure that.

It seems to me that a big reason for this is the rapid pace of exploit developments. Every system-level tool has to be able to quickly adapt to deal with those security issues, either in its own code or in its dependencies, and these of course bubble up the stack, such that you have to keep updating to protect your users. And these updates somewhat regularly force (or make it difficult to avoid) breaking compatibility. So if you're breaking compatibility in small ways, that makes is easier to say "well let me just make these bigger changes, while I'm already here". And of course there's also the competitive aspects of featuritis. And this then causes the "Red Queen's race"[0], similarly to animal evolution, where if you don't adapt to the ecosystem, you go extinct. [0] https://en.wikipedia.org/wiki/Red_Queen%27s_race https://en.wikipedia.org/wiki/Red_Queen%27s_race

jtc331 3y ago
I think the bigger reason is simply that backwards compatibility is hard. Some projects put in that work (e.g., PostgreSQL), but it comes at a significant tax on productivity that could otherwise be put into new features.
- jjav 3y ago
  > I think the bigger reason is simply that backwards compatibility is hard. Backward compatibility requires some care, but it's not exactly hard. Simply don't change interfaces or exposed behavior. You can always add new APIs, just don't break the current ones. The only time it is hard is when there is a security vulnerability that is difficult to fix without breaking compatibility. But that's not very often. I came of age in the culture of never, ever breaking compatibility. You'd get raked over the coals in design meetings for ever voicing such forbidden thoughts. It's a wonderful approach because everything just keeps working. As it should be. The software industry needs to grow up to what it used to be.
- hinkley 3y ago
  When you don't put in that work you're externalizing it onto others.
fouc 3y ago
I think it should depend on the attack surface - is the software on a server that is exposed to the public? If it's relegated to private servers then it is easier to secure that.