The economics of software is, I’d suggest, a particular instance of a more general problem: the economics of knowledge. After all, software is knowledge. All of the “strange” properties that people attribute to software — the high upfront cost, the zero marginal cost, the inversion of the primitive supply-demand model — also applies to knowledge in general. From this perspective, the reason why the operating system is free and the database cost $40K/cpu is quite obvious: everybody and their grandmother knows how to build operating systems but only a very few people in the world know how to build database systems that can satisfy the requirements of a large enterprise. Note that this imbalance of “knowledge” is necessarily temporary; the demand for knowledge about enterprise databases means that more and more people will learn about enterprise databases. (Or they may decide that the cost of learning about traditional databases is too great and invest their learning-time elsewhere.)
The critical question that arises from this line inquiry is, simply enough, what is the real price of knowledge?. This is not so much a matter of what people will pay for the knowledge — the market will decide that — but, rather, what is total future utility of knowledge. Note that the latter will, eventually, barring distortions, come to determine the former. People will pay based on what they think about total future utility is for a given commodity. It’s here that things get interesting. The total future utility of, say, a car can be determined to a reasonable amount of accuracy. But the total future utility of a computer program? Or rather, the total future utility of a computer program’s source code? After all, I think when we speak about the value of a piece of software we simply must be talking about the value of its source code. There are other factors to consider of course but everything begins and ends with the source code.
There’s another factor here which is also very interesting and very important. It’s that the “cost of knowledge” is very much determined by how much it costs to learn and research and explore. That is, if, for whatever reason, you can learn “faster” such that your learning-time is reduced across the board then it should follow that all “knowledge commodities” should become cheaper. This is because it would take you less time to learn enough to develop a replacement. So — and this is where all the traditional economic assumptions about physical commodities fall down — the cost of software and other knowledge products is largely determined by how much it costs to learn.
If that makes any kind of sense than it does suggest an alternative solution of how much to pay for a database. It’s largely a matter how much it’d cost your organization to turn on a dime and develop its own database. This is, I think, a strong argument for Not Invented Here. While in the past I’ve railed against people who write their own XML parsers and the like, I’ve come to appreciate that in many situations it is definitely cheaper and “long-term profitable” for a firm to develop its own solution to a product even if there exists “popular commercial solutions”. If you’ve got the talent, well, then use it. There’s no reason you should pay the same “price” as the less talented for a solution. And this is where open-source also enters the equation. If a problem is widely understood than there’s no reason anybody should ever pay for the solution. And this logic can be extended; even if a problem isn’t widely understood it may make sense, if you possess the talent, to develop your own solution and then share the knowledge and thus drive down the “cost” of the problem. This is what’s so different about knowledge and physical commodities: it pays to share knowledge with others. If you can drive the cost of a problem to zero then not only have you reduced your own costs but you have also reduced the general “cost of learning.” The market isn’t just efficient in this case but, rather, as the various participants become smarter the market becomes more efficient.
The real lesson here is that too often firms focus only on the ROI. The problem with such a simplistic focus on ROI is that it assumes that the firm itself is some kind of unchanging entity. If you only ask the question “how many dollars will $X save?” and “how many dollars will $X generate?” you have completely failed to understand the value of knowledge. Another important question here is, simply, “what will we learn from $X?” Companies can, if those involved, become smarter, they can learn and generate knowledge and, inevitably, everybody will benefit from this new knowledge. So rather than only considering price in any basic build-or-buy decision you might also consider the what you can learn from choosing one solution or another and how that new knowledge can itself be leveraged in the future.