Linux kernel has a huge amount of contributors with their own goals and they seem to coordinate just fine. Monoliths can scale, but they can't be "owned"/leveraged by leaders/sociopaths into a bigger budget/team/etc, IMO.

Linux development is absolutely hampered by being a monolith. Getting involved in Linux development is notoriously difficult. The average developer won't consider it even though there are many parts of the kernel which very much should be approachable. It is also hard to get some patches upstream if the goals of said patches don't align with everyone else's interests. There are even people exploring userspace schedulers to get around these challenges.

There are also huge maintenance burdens that come from the lack of stable interfaces for modules. There is a reason there is a lot of excitement around ebpf. It is providing the sort of scaling that people have been needing for a while.

The linux kernel is more siloed than one might expect, a lot of code is architecture specific or in drivers, which facilitates having a wide group of maintainers.

EXACTLY.

It shows that you can have a siloed monolith.

Not true. Sociopaths always find a way.

I don't agree. Almost every candidate during interview likes to talk how their team of 3-5 people manages multiple microservices. It's pretty much hype driven approach to develop a backend application.

"when an organization grows from tens to hundreds of engineers" - point taken.

My question then is: is this type of growth the norm, or is it exceptional? If I am, say, Tesla... do I need 1 order of magnitude more sw engineers when I start selling 10 times the cars I was selling 2 years ago?

When going from tens to hundreds, do the hundreds manage to produce anywhere near a many-fold increase in performance though?

My impression is that microservices is a solution to keep a hundred people HAPPY (solving auxiliary problems you create for yourself) while producing about the output for the company that the "tens" would provide.

If management INSISTS on scaling from tens to hundreds, you can't very well keep the tens occupied on irrelevant side project. So instead you can do microservices. Either way you get the speed for the company of "tens" though.

Interestingly, open source has some change management processes that deal with orders of magnitude more people and pieces of software than you will find on a corporation, and mostly only imposes infrastructure policies when that's the development's goal.

It tends to fail less often than corporations too. And my impression is that it's more efficient for developer time.