The New Software Economics
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
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.
Tony Baer is principal with onStrategies, a New York-based consulting firm, and editor of Computer Finance, a monthly journal on IT economics. He can be reached via
e-mail at email@example.com.