Monthly Archives: December 2003

Software and commodities

I’m a big fan of Doc Searls, but I think he’s got some basic ideas wrong when he says that the stupidist conceit of the software business is that commodities are bad.
“Commodity” has a number of different meanings dependent on context, but for the purposes of this conversation, let’s take the definition as I understand it to mean in this case: a commercial service or good that is undifferentiated from other goods offered by other producers of the same good.
Going from this definition, commodities in a business context are almost universally a bad thing, because it implies that you, as the producer of an undifferentiated good, have no pricing power in the market. Take Doc’s example of food producers. Over the last hundred years, it’s become harder and harder to eke a profit out of food production. The farmers who still exist (and I’m including large agribusinesses in this mix) are able to do so only by virtue of massive subsidies from the government. Were it not for those subsides, the food producers would go out of business — not a nice place to be.
Producers of food-related commodities, however, are much better off than a hypothetical producer of a software commodity. The economics of software are actually much closer to the railroad industry, where there was tremendous capital costs associated with laying the tracks and buying the trains, but the incremental cost of each train voyage is relatively small.
In business, you always want to be producing something that’s different in some way — ideally, in a way that will induce customers to pay more for that good over the goods offered by your competitors. In the case of stupid networks, that differentiation could be about customer service and reliability, but unfortunately, those often don’t factor into the decision process most consumers follow when choosing a network. Markets producing commodities — where no player has any pricing power — will always tend toward consolidation and monopoly.