> Because I can look at the price of goods versus their cost. A company that owns the production chain for a sub-component is paying the cost of that component, while a company that doesn't pays the market price.I'm not sure I follow. Let's say Acme Inc. produces a widget that is a subcomponent of their larger product. When that subcomponent is within the control of a team of four who works for Acme Inc., the company has to pay the market price (meaning a markup margin?), but when that team is joined with another team who also works for Acme Inc., then they only have to pay the cost?
1. What difference does that make? Even if a markup really was paid on paper, it's just to Acme Inc. itself. You haven't changed anything, practically speaking.
2. If an external entity is willing to pay more for the component, which is what I think you are trying to suggest with market price, Acme Inc. is paying the opportunity cost when keeping it internally and thus is still paying the market price. Are you under the impression that there is a free lunch here? There is not.
> trying to maintain an internal market of software where multiple teams build the same service and compete with each other on who has a better version is crazy
Just as it would be crazy in the macroeconomy. The idea that competition is necessary for markets to work is misguided. You don't need a second road running parallel to the first. One road is just fine. Competition only comes into being when someone thinks they can serve the customer better by doing things differently. Which is a useful property of human dynamics, to be sure, but sometimes things are already as good as anyone is able to imagine.
> they started collaborating on Linux
As individual teams, with another team headed by Linus who accepts the services of those other teams as seen fit. Another great example of the service economy in action. No need for a monolith – if such a thing were even possible, but as pointed out at the beginning of this, of which I agree, we don't actually know how to build monoliths, no matter how great they sound in theory. There are outstanding problems not yet solved.
> They are built as monoliths with large teams working to add features and collaborating relying on a hierarchy of maintainers
A monolith, but also hierarchal? Uhh...
> I don't see any proof whatsoever that building a company or a product in general out of a marketplace of dozens or hundreds of very small teams has ever worked beyond maybe some niche cases.
I suppose you can take the perspective that nothing works, but given the outstanding problems not solved to allow anything else, something that doesn't work beats nothing at all. Worse is better, perhaps.