Columns

The New Software Economics

• By Tony Baer
• May 30, 2001

How much do you really pay for software? For the history of computing, the answer has been, "It depends." For developers, the answer has long been, "Who cares?" There are good reasons, however, for software developersto start getting more concerned over licensing issues. And we're not just talking about arguments over the extra costs for run time. What is even more intriguing is an attempt to do away with software licenses altogether.

In the early days, you paid for hardware and wrote programs using primitive languages that were, more often than not, thrown in almost for free. As higher level languages replaced machine code and commercial software applications began emerging, software was valued as more than just the physical media on which it was stored. The era of MIPS-based software licensing was born.

Yet MIPS pricing still reflected the view that hardware was the main value. This pricing structure was like real-estate taxes: you paid more for software based on assessed hardware values in the same way that property taxes are based on the assessed resale value of a home. Move to a bigger house, pay more property tax. Move to a bigger machine, pay more for software. Nobody liked it, but at the time no one had any better ideas.

Client/server technology soon made MIPS pricing irrelevant because functionality migrated to the desktop. User-based pricing and runtime licenses made their debuts. The idea was that these pricing structures were better gauges of actual use because they were based on either the number of named users or the maximum number logged in at any one time.

In some cases, software vendors became even more elaborate. For development tools, which were actively used by small developer teams, but whose value came with deployment to hundreds of end users, the result was a tiered system of development and runtime licenses. For packages, it was a tiered system of power users, back-office users and, with the advent of HR intranets, self-service users. Naturally, no one liked these pricing schemes either.

Given the changes in licensing that occurred when client/server came about, it shouldn't be surprising that the Web is causing things to stir once more. This time, however, there are a few twists that not only change the nature of software and the role of vendors, but ultimately validate the role of IT.

For intranet Web applications, the result is a tweaking of the user-based licensing model. In other cases, including intranets that go out to large populations of casual users, and extranet and Internet applications - where the user base could be huge, if not impossible to count - the result is a return to mainframe-like processor pricing.

What is most intriguing, however, is the attempt to do away with software licenses altogether. The idea has two parents: The Application Service Provider (ASP), which provides the 21st century answer to time sharing, and application software vendors, who are looking for smoother revenue streams to avoid repeats of the recent dive in ERP revenues.

The result is that licenses might be turned into application rentals. That is great for lean, often cash-starved mid-tier companies or hot start-ups because these organizations generally don't have a few hundred thousand dollars or a million dollars to spend up front. Another possibility, which is even more intriguing, is one where the software vendor stops being a software vendor and becomes part of a business service that charges by the transaction. Software vendors such as Oracle, SAP, i2, Ariba and others are planning to set up online trading communities where revenue comes from either a transaction or as a percentage commission of an online sale.

The implications of these changes go far beyond software vendors themselves. By changing their charge schemes, as well as their roles, vendors are stating that software no longer supports the business, it is the business. The ramifications are potentially staggering for software development teams because in developing applications or functionality, they are developing the business itself or specific business processes. In other words, development teams are no longer viewed as cost centers, but as profit centers.

And that means that the huge salaries being paid to Java developers, DBAs, object-oriented designers and others no longer appear to be so outrageous. No one will like these fees either. But this time, the argument won't be over the fairness of run times. Instead, it will be the fairness of transaction fees to the bottom line.