It's the users who need to audit, the social contract of OSS is just not to be sneaky/sloppy about it (when posing as a serious project).
Semvar is beautiful bc it lets you be explicit. Likewise, end users can judge "wow major version 27 in as many months, maybe not so good for us." We had a gov customer today upfront about needing slow updates, and same deal -- maybe our SaaS and OSS libs are too fast moving, so they are probably better off with our enterprise distros.
I am a toil/backwards incompatibility hawk. I don't like to impose them on my customers. It's extremely rare that the balance of equities favors making a change like this, where a function that filters data and will necessarily impact correctness is changed, and not in subtle edge cases but in its primary behavior. In fact, I've never seen a case in my career where it ended up being worth it.
I'm a big fan of Linus' mantra: we don't break userspace.
I agree - we probably err too long on avoiding breaking legacy code: we are about to do our first deprecation in years as the old protocols are getting too unconscionably insecure + costly to maintain relative to our new ones.
But that's company code we get paid to be stable on. Very diff story for OSS we at most contribute to, we don't assume that's part of the social contract.
Linux is also OSS. I don't think this is an OSS/paid dichotomy. This is a good software/bad software dichotomy. Also isn't this library maintained by mongo db anyway? So the "we are doing this for free" excuse does not apply.
Agreed in part, I'd indeed want careful motivation and change management of such a change from my language or DB vendor -- JS/Python takes years for tinier semantic changes :)
The average OSS project is just ~1 fulltime maintainer, maybe 2, with tiny drive-by contributors: there are great studies measuring this. Even most popular and long-lived OSS projects are more like that than Linux. The exceptions are inspiring, but most (my bet, I don't recall stats here) seem to be open core largely driven by 1 company. Something foundational with many contributors under open governance like Linux is better to discuss as an abnormality ("why can't the typical project grow to this size, maturity, tooling, and stability?").
So when talking about modern OSS, the typical case of looking through a pip or npm tree is NOT big shops and instead something closer to a network of volunteer passion project. From such individuals, I'm thankful for semvar, CHANGELOG, CI, and a few niceties like that. From there, the history of BREAKING would signal the project moves too fast for us or with too big swings, or looks more acceptable.
Where I work, the biggest enterprise system we have (ERP) has has a support cycle of ToS upgrades quarterly, with only urgent security patches in-between. And detailed advisories ahead of time on which (depending on modules and features in use) must be updated, may be updated, or can be ignored.
It makes maintenance a highly predictable endeavor:
Update T+0 == dev instance
Update T+1 week == test instance
Update T+2 weeks == prod deployment.
UAT inserted as needed when there are user-facing changes.
Semvar is beautiful bc it lets you be explicit. Likewise, end users can judge "wow major version 27 in as many months, maybe not so good for us." We had a gov customer today upfront about needing slow updates, and same deal -- maybe our SaaS and OSS libs are too fast moving, so they are probably better off with our enterprise distros.