4 ms·
> 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,
by randomdata 2y ago
> 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.
- tsimionescu 2y agoI think this whole thread may be at least partly a misunderstanding. The way I see it, the discussion began by saying that any team (but in context, referring to a whole company) that grows past a certain size needs a traditional hierarchical system of layers of management to function. Then, someone said that a team/company should just not grow past 4-8 people, and thus you avoid the need of hierarchical management. My point is that this idea makes no sense. A company can't function as a composite of hundreds or thousands of sled organizing small teams without any management to coordinate them. My understanding is that you claimed that such a thing is possible, and that in fact it is how the free market and thus the economy of most nations actually functions, without any hierarchy. I was then rebutting this by showing that the economy does form hierarchies (with large buyers essentially viewing small sellers as subordinates, not independent market actors, when they're not outright buying them). So, I would argue, the economy is not generally organized as a bunch of independent small orgs, but as a series of huge conglomerates that either own their suppliers, or at least dictate market terms for some period with contracts. The idea of a free market where buyers and sellers meet and negotiate prices based on supply and demand is largely a myth, with some limited exceptions. As such, the hierarchy in how Linux is built is in line with my original idea: not supply and demand based, but instead organized in a relatively rigid hierarchy. In support of why I'm claiming that this system of hierarchies arises due to efficiency, I gave the example of how much it costs a company to buy a piece they need versus how much it costs them to produce it internally. This is meant to show that a supply&demand based self-organizing market (the flat, many small teams without managers model) is less efficient than an integrated supply chain (the top-down hierarchical model, with layers of management).
- randomdata 2y ago> and that in fact it is how the free market and thus the economy of most nations actually functions, without any hierarchy. There is a hierarchy of sorts (realistically, something more like a cyclic graph, but close enough for all intents and purposes). The customer gets food from the grocery store -> who gets food from a wholesaler -> who gets food from a processor -> who gets food from the farmer. But at no point, despite being an exceptionally complex system, do you need to exceed a small number of people per team. > thus you avoid the need of hierarchical management. Right, so I expect this is where the miscommunication is happening. You're not wrong that the consumer of food manages the grocery store. Absolutely that is true. Of course it is. And in that sense, some kind of hierarchical (or whatever we want to see the graph as) management will emerge. That is a necessary precondition for an economy to exist. Contextually, though, management was seen in a more vileness way, which does tend to happen when communication overhead starts to overburden the people, leaving actors to be faceless "cogs". This is what small teams avoid. > but as a series of huge conglomerates Which don't operate as monoliths. Internally they function as a series of smaller businesses, and inside that even smaller business, until you whittle the teams down into a small number of people. Maybe not exactly 4-8, but certainly within that order of magnitude. A person can only communicate with so many other people before all hours of the day are exhausted. > The idea of a free market where buyers and sellers meet and negotiate prices based on supply and demand is largely a myth Okay... Sure? Is there some reason for us to randomly start talking about a "free market" here? It was never mentioned before. > not supply and demand based I don't follow. Supply and demand is not some kind of foundation on which something is based. It is observance of social behaviour, typically that of humans, but applies even to animals. Supply and demand is every bit as much present in the development of Linux as everything else humans do with other humans. It is fundamental. > but instead organized in a relatively rigid hierarchy. Instead? They are not at odds with each other. > I gave the example of how much it costs a company to buy a piece they need versus how much it costs them to produce it internally. Which didn't seem to serve a purpose. If all else is equal, it costs the same. Presumably you are referring to a case where you can buy a subcomponent externally for $10 or produce it internally for $5? But given that buyers are willing to pay $10, you lose $5 every time you keep it for internal use. So, in both cases, it costs you $10. There is no free lunch. > This is meant to show that a supply&demand based self-organizing market (the flat, many small teams without managers model) is less efficient than an integrated supply chain The data doesn't support this, though. Statistically, smaller businesses in coordination with each other are more efficient. You'll notice large businesses only become large when they can build some kind of moat. In the case of software, that mostly means hiding behind copyright and patent protections.