[MaxBarraclough]

I'm reminded of a blog post I once read, which annoyingly I now cannot find, on how the job of a library maintainer is to not break the API. If you break the API, you've failed at your job. This mindset makes more sense than treating API breakages as a routine case-by-case decision. As the article puts it, breaking changes are breaking the library's commitments. (The library/service distinction doesn't matter much here.)

I remember that same old blog post also lamented overhearing a conversation in which a developer bragged about how their idea for a change was so good that everyone agreed to break the library API to implement it. This reminds me of how a startup being 'highly disruptive' is sometimes fetishised as an end in itself, but of course it's even worse than that: they're celebrating undermining the library's dependability.

[jeffffff]

sounds kind of like this famous linus rant: https://lkml.org/lkml/2012/12/23/75

[jbverschoor]

Linus is 100% correct here.

Too often it’s “a user error”.. no, it’s a platform/developer/provider ak lower level error or mark of laziness

[geranim0]

Is he always like that? That's toxic af

[icebraining]

https://lkml.org/lkml/2018/9/16/167

[fallenpegasus]

Complaints about "toxic" are a screen to hide the fact that you can't say "incorrect".

[plorkyeran]

He has toned it down significantly in the last few years.

[meshaneian]

"Yes."

[giancarlostoro]

Agreed, that is probably why you wind up with a lot of versioned Microsoft C++ runtime installers on your computer, but damn it at least the reliant software works as intended.

[monadic2]

A library being dependably bad is not good. Sometimes changes really are good enough to break an api. It does take a significant amount of communication to do this without pissing people off, though.