One theory I’ve heard (I think from Yegge?) is that Google’s internal tooling is so good at dealing with breaking changes that they’re too cavalier about introducing them.
A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. But they don't have to answer to "the business" or huge institutional users. Commercially driven open source will always be a product beholden to stakeholders, rather than technology designed to operate as well as it can.
And regular users hate this.
Jamie Zawinski describes this funnily, eloquently and also offensively:
https://www.jwz.org/doc/cadt.html
> This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
But he's right, and that's why:
* regular application developers who don't care about ideology
* and mass market users
hate desktop Linux.
Users just want stable software. Developers want software that works better and solves more problems. The compromise is for users to stick with old major versions. At some point that's no longer tenable, but at least this way the software is free. Certainly no worse than when the same thing happens but you're paying for it.
i think the interesting thing is that while you’d think that is the ideal everyone should strive for, the reality is that’s inapplicable or detrimental to run most businesses that way.
I'm confused, did you mean "without" instead of "with"?
Also:
> i think the interesting thing is that while you’d think that is the ideal everyone should strive for, the reality is that’s inapplicable or detrimental to run most businesses that way.
Why would you say that is?
> Why would you say that is?
many/most businesses don’t have the margins/scale/time to focus on it. in a lot of businesses (amazons included) the goal for the business is to try as many things as fast as possible and scale that which works and abandon what fails. the goal of infrastructure there is to get out of the way and enable the layers above to build things as naively and simply as possible with little to no churn.