Software Economics: The Declining Price of Software Over Time
IBM is once again giving away some software; after donating its VisualAge tool to Eclipse and so many other products to greatly invigorate the open source movement, this isn’t so surprising. What’s more interesting is that these donations seem to be moving higher up the value chain, as IBM will reportedly begin giving away a Universal Database Express-C version of its high-end DB2 database that will run on up to two-chip systems.
It seems to me that a sign of a healthy software ecosystem is the gradual price decline of particular packages as they grow more complex. One example would be Microsoft’s bundling of Word, Excel, PowerPoint and various other packages into Office, which doesn’t cost nearly as much as the total prices of individual packages 15 years ago, especially after adjusting for inflation. Excel itself, when introduced on the Mac, had consolidated functions previously handled by Multiplan, Chart and some other programs.
One of the common signs that a particular software ecosystem is declining is that this trend of generosity on the part of the ISV reverses, and it starts to look for ways to increase unit revenues. This is one of the reasons why I suspect that much of Microsoft’s software business isn’t as healthy as it once was, as they have at least begun to make changes in their licensing/pricing that for some customers might be viewed as an effective price increase.
Some vendors, such as Computer Associates, seem to have done fairly well by buying up aging software and gleaning what they can from the remaining user base, many of whom may prefer to stay with what they have been using for quite a few years. Though potentially an opportunity for exploitation, if managed with restraint such a business can provide a valuable service, by keeping users from languishing without vendor support.
Nevertheless, in a healthy, growing software ecosystem the price of packages should normally decline, since the user base is growing (allowing development costs to be spread over more units) while development costs should be moderating as the product matures. Actually, while the first effect is often realized, for some reason (perhaps Parkinson’s Second Law - expenditures rise to meet income) the second is more difficult to achieve.
As sales of its software rises, a successful software vendor will typically add features while keeping steady or lowering the price. Though holding the line on costs, in the real world the size of programming staffs generally seems to balloon, which gradually works to reverse the virtuous cycle of generosity. This excessive growth in programming staff is a curious outcome which I suspect results from management’s desire to speed development in response to competition, despite Fred Brooks’ showing over thirty years ago, in his classic essay “The Mythical Man-Month“, that such an approach is generally counterproductive.
Peter Drucker frequently argued (e.g. Managing for Results, Ch. 9) that one of the biggest problems in business is vendors’ unwillingness to kill off their own aging products, thereby retarding innovation and eventually causing loss of markets to more innovative upstarts. I suspect a software ecosystem requires a modified form of systematic abandonment, where products gradually decline in price and eventually are given away, either as open source or as an inducement to attract new users who may upgrade a to a vendor’s more advanced offerings.
Vendors also ought to consider still selling at a lowered price older versions and upgrades of their software (at least as long as these are supported) since this might be a good approach to segmenting the market between higher-spending customers with newer hardware and budget-conscious buyers using older hardware (and might induce additional upgrades as the cost declined).
Of course, much of the business motivation for open source comes from recognition both of the need to continue stimulating a software ecosystem to attract new users (as many are attempting to do now with Java) and that much of the revenue opportunity comes from services and other add-ons, which seem also to be a fairly effective way to segment the market.
Every industry has its own unique economics. I remember a database seminar once in which a vendor rep described how he had worked with grocers, where the prices, discounts and other factors changed constantly. Airline economics, with which I’ve been fascinated for years, is another very difficult area.
Software, too, has its own sort of economics, driven by the vendors’ desire to smooth out the revenue stream (development is steady but revenues tend to bunch around releases), the extremely low unit marginal cost, and intense competition amidst constant technological change. I’m surprised there doesn’t seem to be more active discussion of the unique economics of software, as this might help to reconcile vendors and the open source community.
Software has been the “sick man of technology” for some years now, with disappointing advancement (despite incredible gains in hardware) and recurrent schedule slips. A better understanding of the underlying economics might go a long way in producing a newly healthy software industry.
