He mentioned in the article that Kubernetes didn’t have a Linus Tovalds to oversee the project. I found a similar thing to be true with git, as often scaling isn’t so much a technical challenge at first, rather it’s a bunch of org challenges that manifest themselves in technical ways.

The model of the “benevolent dictator” kinda works in this case. My last project I was on we managed to scale to about 50k LOC without anything special, the key is I knew the repo like the back of my hand and could catch potential integration issues. While the model works well, it’s very hard to setup as you need a real nerd of a team lead to constantly watch the repo.

I'm still not quite sure how that counts as breaking git?

If you misuse a tool, and the tool performs poorly at the job it's not designed for, but never fails in an unexpected way, and still maintains all the functionality it always had, how have you broken that tool?

If try to hammer in a nail with the butt of a screwdriver, and make a complete pigs ear of it, but the screwdriver absorbs the abuse and is still perfectly usable as a screwdriver afterwards, did I "break" the screwdriver?

Or, am I misunderstanding how the word "breaking" is being used here? Is there a meaning I'm not getting?