Making breaking changes and pushing them to your customers without warning is bad, no question. Staying compatible with everything forever is equally bad, but

Making breaking changes and pushing them to your customers without warning is bad, no question. Staying compatible with everything forever is equally bad, but we only realize that over relatively long timescales. I think there's a middle-ground between these two extremes that hasn't been explored: when you make an incompatible change, fork. Patch only the worst bugfixes and security fixes on old forks (but continue these indefinitely). Point new users at the latest fork in each point in time. Support switching forks on your users' schedule. This approach adds some overhead for authors and maintainers. But I think it's not as much as we fear. And it can be automated over time. There's a selfish reason this never happens, but we don't talk about it in polite company: if you start forking yourself you make it more acceptable for others to fork you. I think that's a good thing. We should all stop playing shallow politics and encourage being forked by others.