WHAT IS YOUR

SOFTWARE
WORTH?
By applying well-known principles
of intellectual property valuation,
sales expectations, growth of
maintained software, discounting
to present value, and the like, a
method is presented for valuing
software based on the income that use of the software
is expected to generate in the future.

B y G i o Wi e d e r h o l d
There exists voluminous literature on cost estimations for
producing software, but that literature largely ignores the
benefits of using that software [4]. Even software engineering
management approaches termed “earned value management”
only deal with expenses within a development schedule [1].
While software creators believe their product is valuable, they
rarely quantify its benefits. Much investment in software engineer-
ing has been motivated by military and governmental applications,
where benefits are indeed difficult to quantify. When benefits of soft-
ware in commerce must be quantified, it is typically left to lawyers, econ-
omists, software vendors, or promoters to assign value to our products.
The results are mostly inconsistent [8].
Why should software creators care? In many other fields the creators have a sub-
stantial awareness of the value of their products. Architects are aware of the market
for houses they design and builders of bicycles will know their market. But since soft-
ware, once written, is easy to replicate at a negligible cost, each subsequent instance
is sold for much more than its incremental cost. Potential sales volume is a key fac-
tor required to set a price allowing an adequate future income. That income deter-
mines the value of the product to the creator.
illustration by paul wiley

COMMUNICATIONS OF THE ACM September 2006/Vol. 49, No. 9 65

 T
he value of software to a purchaser is where knowledge and talent creates the intangible
independent of the cost and effort goods we need and desire. Many approaches for val-
spent to create it. A few brilliant lines uation compete [5]. Tangible goods are produced by
of prose or code can have a very high a combination of labor, capital, machines, and man-
value, whereas a million lines of code agement; the quality of the human components
that generate a report that nobody plays a minor role in valuing such a company. Even
reads have little value. If creators are aware of the today, the book value of a company given in its
potential value of the product they will be better pre- annual report is merely the value of its facilities,
pared to make decisions on product design and the inventory, equipment, and finances.
effort to be expended. The motivation for this article That book value has little to do with how investors
is to increase the awareness of the computing com- value companies in the software domain. For exam-
munity how the result of their work may be valued. ple, we obtain SAP’s annual report for 2003 and learn
That should, in turn, affect how software engineering that its book value (assets - money owed) was about
is practiced. e6.3 billion. But using the market price of the shares
I first present the principles of valuing intellectual (about e100) and the number of shares in circula-
property (IP), based on the income generated by a tion, about 315 million, we find that SAPs share-
software product. The valuation addresses software as holders valued the company at e31.5 billion. The
it exists at some point in time, and ignores the cost of investors in SAP base the value mainly on the income
its creation. Once the value of the product is esti- they expect to obtain over time from their shares. The
mated, one can compare that value with the cost of its difference, e25.2B, is due to the intangible property
creation and decide if the overall project is profitable, owned by SAP and its shareholders. The value of the
or, if it seems not to be, what must be changed to SAP brand in 2004 was estimated at e6.8B. Soft-
make it so. ware, and the knowledge of how to produce, improve,
Software, since it improves and grows over time, and sell it, comprise the rest, e18.4B. U.S. high-tech
presents novel issues not seen in other intangibles as companies show similar ratios, but no routine report
music and books. Maintenance to sustain software provides valuations of their intangibles [11].
effectiveness occurs throughout the time the software The intangible property owned by a company in
is in use; that is, while the software actually generates the knowledge-based domain includes the technical
benefits. Maintenance costs over time typically exceed knowledge of its staff, the competence and insights of
the original software development cost by factors of 2 its sales force, the business knowledge of its manage-
to 10. Maintenance causes growth of software, and we ment, the worth of its trademark, its reputation, and
show here how three types of maintenance efforts the value of its software inventory.
together affect growth and value. The growth of soft- The reputation of a software company can be
ware will also be modeled using some rules-of-thumb increased by advertising and the value of its software
derived from experience. can grow by research and development. These two
After the discussion on the diminution of software components are the considered IP of a business. The
IP we predict sales volumes for software. Standard work force of a company cannot be considered a
business methods are presented, selected for their property. Valuation of IP is required when software
suitability in modeling software sales. We then com- product lines are purchased or transferred. When
bine prior results to compute the value for the exam- entire companies change hands, then the work force
ple. To illustrate the use of a quantitative model for is assigned a value as well. Although software is the
analyzing alternatives, we include maintenance most tangible of the IP owned by businesses, its valu-
income, representing a service-oriented business ation is still poorly understood, leading to a gamut of
model. We conclude with some advice for individu- problems [8].
als, managers, and educators. The value of software IP. Investors in a software
The goal of this article is to bring together infor- enterprise assert through their stock purchases that
mation from domains that rarely interact directly:
software engineering, economics, business practice, IP RULE: THE VALUE OF THE INTELLECTUAL PROPERTY IS
and legal sources. THE INCOME IT GENERATES OVER TIME.

PRINCIPLES OF IP VALUATION That simple rule is the basis for any IP valuation.
Assigning value to intangible property is assuming Estimating that future income and reducing it to a
greater and greater importance, as our society moves single current value is the task to be undertaken [11].
from dependence on hard, tangible goods to a world This article focuses only on software, likely the

66 September 2006/Vol. 49, No. 9 COMMUNICATIONS OF THE ACM

largest IP component owned by companies involved it as a distinct income-generating investment becomes
with computing. Ownership of software is not limited impossible. Today, it is rare that a broad set of new
to companies that produce software as a product. The software applications will be installed within an ongo-
majority of current businesses creates, purchases, ing company. A company employs many diverse
maintains, and benefits from software. Banks cannot resources to generate its income. Income can still be
function without software; there is no other way to assigned based on a belief that the management of a
determine what is due to a customer or what the cus- company is rational in the allocation of its resources—
tomer owes. Manufacturers cannot live without soft- a standard textbook assumption.
ware; the designing process, obtaining and allocating
resources, managing the workflow, and shipping the PARETO RULE: AT THE OPTIMUM EACH INVESTMENT
goods out all depend on software—and companies DOLLAR SPENT GENERATES THE SAME BENEFIT.
that exploit software better will be more profitable.
Estimating income. To value the IP inherent in If a company spends more than optimal on soft-
software, one must estimate how much income ware and less on people or marketing it would reduce
the software will generate during its its income, and vice versa. Given that rule, corpo-
future life, which also requires estimat- rate net income created by diverse expenses can
ing its life. We distinguish here soft- be allocated according to the proportion of
ware producers and software users. costs incurred. The fraction spent on software
If the software produced is sold from year to year will vary, but over its life
to others, the expected income such variations even out. If a company behaves
depends on the sales revenue, the irrationally in its spending, more so than its
product of the amount of software sales, and its peers, it is bound to have lower net profits, and its
price. We assess the software from the viewpoint IP and its stockholders will suffer as a result.
of the seller. When a new version of a software Income-based measures don’t work in gov-
product has been prepared and is ready for sale, ernmental and military settings. In those
sales of the prior version will rapidly diminish. organizations measures of productivity and
Since the costs of copying and packaging soft- cost-avoidance must be combined to
ware are very low, there is no benefit in con- produce a surrogate for income. In those
tinuing to sell the old software, a characteristic settings, and in other non-profit institu-
particular to intangible property. Software differs tions, as academia, using an assumption
from other intangibles: while a book written and of rational behavior for relative alloca-
printed two years ago can be profitably sold for, say tion is also questionable. Valuations of
80% of its new price, selling a prior version of soft- software will hence be quite inexact and
ware at an 80% price makes no sense for the seller. mainly useful for making comparisons.
Supporting old versions is only a cost for the seller, Revenue and gross profit. In business financial
while being out-of-sync creates inefficiencies for the reporting the revenue realized is immediately reduced
customer. by the cost of the goods sold. The effort to make the
Furthermore, the new version will be better than first unit of a product is a major cost in both cases,
the previous version. For the purchaser obtaining but for software the manufacturing cost-of-goods is
cheap, but obsolete software creates expenses for adap- negligible. If software distribution is over the Inter-
tation and integration. A new version of the software net, there are no incremental costs for each sale. Rev-
product includes much of the code and all of the enue and gross profit, the revenue after the
functionality of the prior version. Disasters have cost-of-goods sold, become similar, and common
occurred when new versions did not replicate all prior financial indicators, as gross margin, are close to one
functionalities [12]. and meaningless.
If software is developed and used internally, valuing Since we only assess here the value of existing soft-

If creators are aware of the potential value of the product they will be better
prepared to make decisions on product design and the effort to be spent.

COMMUNICATIONS OF THE ACM September 2006/Vol. 49, No. 9 67

ware, we ignore its initial research and development cost cessful, the product will not be accepted in the
and its negligible manufacturing cost. Now the income marketplace and not have any significant life.
per unit is equal to the revenue, that is, the price it • Adaptive maintenance is needed to satisfy external
fetches and the sales volume over its life. However, there mandates. Adaptations allow the software to deal
will be ongoing costs to keep the software viable. with new hardware, operating systems, network,
browser updates, as well as other software used in
SUSTAINING SOFTWARE the customers’ environment. Software must also
Before we can aggregate the income generated by be adapted to changing governmental and profes-
software in order to value its IP, we must consider sional regulations.
what happens to software over the time it generates • Perfective maintenance keeps the customer happy
income. It is here where software differs crucially and loyal [2]. Perfecting includes performance
from other intangible goods. Books and music upgrades, assuring scalability as demands grow,
recordings remain invariant during their life, but keeping interfaces smooth and consistent, and
software keeps on changing. being able to fully exploit features of interoperat-
Methods used to depreciate tangibles as well as ing software by other vendors, as databases, Web
intangibles are based on the assumption that the services, schedulers, and the like. Perfecting
goods being valued lose value over time. Such depre- makes existing software work better.
ciation schedules are based on wear, the loss of value

B
due to obsolescence, or changes in customer prefer- ug fixing for software accepted in the
ences. However, well-maintained software, in active market eventually reduces to less
use, does not wear out, and is likely to gain value [12]. than 10% of the maintenance effort.
All substantial business software must be sustained Adaptation consumes 15%–50% of
through ongoing maintenance to remain functional. the maintenance costs. That effort
What maintenance provides was stated many years needed varies with the number of
ago by Barry Boehm [4]: interfaces that must be maintained. Perfecting soft-
“.. The majority of software costs are incurred dur- ware is known to require about half of maintenance
ing the period after the developed software is costs in the long term. Marketing staff often touts the
accepted. These costs are primarily due to software results of perfective maintenance as being novel and
maintenance, which here refers both to the activities innovative, even when base functionality does not
to preserve the software’s existing functionality and change.
performance, and activities to increase its functional- The effectiveness of maintenance is greatly hin-
ity and improve its performance throughout the life dered by poor design and lack of adequate documen-
cycle.” tation [3]. Well-designed systems will be improved
Successful software products have many versions, more rapidly, have a longer life, and hence, paradoxi-
long lifetimes, and corresponding high maintenance cally, consume more maintenance [6]. Figure 1
cost ratios over their lifetime. Software lifetimes depicts relative effort distribution over time; in prac-
before complete product (not version) replacement is tice the ratios will differ depending on the setting and
needed are typically 10 to 15 years, and are likely to on external events.
increase [11]. Version frequency is determined by the Good maintenance keeps existing customers
rate of changes needed and the tolerance of users to happy and improves the product being sold. A high
dealing with upgrades. level of maintenance retains customers (it is easier to
Maintenance costs of such enterprise software keep an old customer than to gain a new one) and
amount to 60%–90% of total costs [10]. Military gains income (good maintenance has a high value to
software is at the low end of the maintenance cost the customer). Fees for maintenance can contribute
range, but is poorly maintained and instead requires in time more revenue than new sale licenses.
periodic replacement. Its users can’t complain much. Sources of IP in the maintenance phase. Mainte-
Continuing improvement. We use IEEE standard nance is too often viewed as work requiring little
definitions for the three classes of long-term mainte- expertise. That view ignores the contribution of the
nance. Collecting and responding to feedback, crucial diverse information sources needed for maintenance.
to IP generation, is detailed next. Corrective maintenance is based on feedback from
the users and customers. Error reports will be logged
• Corrective maintenance is essential to keep cus- and filtered so that only significant problems are for-
tomers. In practice, most required bug fixing is warded to the engineering staff. Corrections are often
performed after software delivery. If it is not suc- needed when unexpected cases or novel combinations

68 September 2006/Vol. 49, No. 9 COMMUNICATIONS OF THE ACM

of usage are identified. If the original developers are times are counted only once to obtain the IP. If mod-
still involved, fixing bugs becomes an opportunity to ules have been written in multiple languages, then
learn, rather than a task to be dreaded. Code to deal conversions must be made. The function-point (FP)
with those cases is added, and so the software grows. literature provides tables that relate them to code for
Adaptive maintenance is based on information many languages [7]. Common procedural languages
from standards bodies, from hardware vendors, from have ratios of about 100 SLoC to one FP, while Visual
software vendors who make products that interface Basic is rated at 35 SLoC/FP, allowing normalization.
with the software, and from government sources. Binary code sizes require adjustments as well.
Major suppliers have representatives at many external Relative value of old and new code. We measure
organizations and vendors. It is rare that prior inter- code sizes to allocate its relative contribution to IP. The
faces and capabilities are removed, thus the software assumption we will make, namely that the value of a
grows. unit of the remaining code is just as valuable as a unit
Perfecting software is a of new code, simplifies
process, perfection is elu- the IP analysis in the next
sive. Perfecting requires 100% section. This metric pro-
the entire organization to Corrective vides a surrogate to track
maintenance
listen, prioritize, and act 80% IP growth over time.
on feedback. Open- There are valid argu-
minded sales staff can ments that code size is
provide the best input Adaptive 60% not a surrogate for the IP
[6]. For instance, no sci- maintenance contents. One argument
entific method assures 40% is that later code, being
that interfaces with more recent, represents
human users will be Perfective more recent innovation,
20%
attractive; there is more maintenance and hence should be val-
Lifetime
variety of customers in ued higher. An argument
the global market than in the opposite direction
any specification can that the basic functional-
encompass; and there will Figure 1. Maintenance effort over ity is represented by the initial code. There may have
the lifetime of software.
always be new uses for been a few lines of brilliant initial code, slowly buried
software that with some in a mass of subsequent system interfaces and later
changes can be catered to. Gio fig 1 (9/06) tweaks and fixes, that are critical to the IP. The archi-
Perfecting updates should not disturb current users. tectural component of software also represents valu-
Perfecting software is a major contribution to growth. able IP and changes little over the life of the software.
The inputs that lead to maintenance actions repre- Much more code is inserted later to deal with error
sent IP not present in the original product. Hence, conditions that were not foreseen originally. Code
they should not be valued as part of the original IP. that was added during maintenance has its value
mainly in terms of providing smooth operation and a
GROWTH OF SOFTWARE high degree of reliability. The original code provided
Since software IP is embedded in the code being the functionality that motivated the customer’s acqui-
used, and that body of code changes over time, we sition in the first place. If that functionality would
must now measure what happens to the code and its have been inadequate the customer would not move
functionality. to any subsequent version. However, new code will
Two metrics are in common use for estimating include adaptations and perfections that motivate
code size and effort: Lines-of-code and function additional sales.
points. Both have problems, but they also comple- Given that the positives and negatives can balance
ment each other. each other out, it is reasonable to assign the same
The size of programs can be measured once the value to lines of old and new code to measure the IP
software is completed. One can look at lines-of- contributions in software. As long as the methods to
source-code (SLoC) or the volume of binary code. obtain metrics are used consistently and without bias,
Some adjustments are needed in either case. When the numbers obtained will be adequate for the inher-
counting SLoC comment lines should be ignored, ently difficult objective of valuing software.
and multiple statements on a line should be counted Growth of code. The maintenance activities that
distinctly. Software modules that appear multiple sustain software cause the software to grow in size, as

COMMUNICATIONS OF THE ACM September 2006/Vol. 49, No. 9 69

 previously discussed. Hennessy and Patterson pre- code due to growth is 50% in Version 2, 33% in Ver-
sented a rule that software, in terms of lines-of-code, sion 3, 25% in Version 4. By Version 3 software
grows by a factor 1.5 to 2 every year. However, this growth obeys Bernstein’s limit. In the early phases of
rule implies exponential growth, expected for hard- a product a higher rate of growth is certainly possible;
ware, but such a rate of growth cannot be sustained in all the original developers are likely to be still on
software development. Phil Bernstein of Microsoft board, there is good understanding of the code, and
has suggested that feedback from the field can be rapidly accommo-
dated, so exceeding the PB rule limit initially seems
PB RULE: A NEW VERSION OF A SOFTWARE PRODUCT acceptable. If the valuation is for a later version the
SHOULD CONTAIN LESS THAN 30% NEW CODE. subsequent growth will not appear so rapid.
For simplicity we consider the initial IP repre-
Substantial growth implies too many code interac- sented by remaining amount of code from Version 1
Figuretions
2. Code in the new and
growth version, reducingof reliability.
diminution Cost through
earlier contributions overthe years. In Figure 2 that amount is repre-
time.
estimation tables support such barriers [7]. Complex- sented by the darkest blocks. In our example we ana-
ity limits were clarified in Fred Brook’s essays: since lyze seven versions, each lasting 18 months, for a
10-year horizon. We adjust the results
to the end of each year, since income is
Relative counted at the end of each year.
Code Size Tv4 x 1.5 Code scavenging. Some code is scav-
4 V 1 enged, during maintenance that is,
New Versions V New code in V4 = deleted and replaced by new code. In
V1+ D x Tv4 x V3
Rule DR: V3 = 3 x V1
V4
practice the rate of code deletion is
V3
small, about 5% code per year, and
2 V3
mainly associated with module replace-
V2
Replacement rate ment. There is little cost to leaving code
V2 D = 5% / year
1 V2
in place, since the amount of memory
V1 V1 V1 T2 V1 T3
and storage available has outstripped
V1 T4
0 the growth of code. But there is a high
Relative 1 2 3 4 5 6 7 8 9 10 Years risk to removal, since some user’s pro-
Contribution V2 V3 V4 V5 V6 V7 V8 gram may still depend on features that
1.00
Price depend on that code. Removing code
0.75 V2 V3 V4 = co
nstan
t New code takes more time than writing new code.
0.50
V1 V2 V3
Contribution
0.25 V1 T2
V1 T3
V2
of V1 GW RULE: WITHOUT INCENTIVES, 5% OF
V1 T 4
THE CODE PER YEAR IS REPLACED DURING
MAINTENANCE.
programming and programming management effort Figure 2.
Code growth
grows exponentially with size, a growth that is more and diminution The limit of removal of code for a
than linear cannot be supported in practice by rea- of earlier new version, even after several years,
Gio fig
sonable growth programming 2 (9/06)
staff. We could validate contributions appears to be 20%–25%. Beyond that
over time.
a rule reported by David Roux that defines a more level it is better to rewrite the code [6].
modest growth rate: However, wholly new code entails
severe risks of creating incompatibilities for existing
DR RULE: SOFTWARE GROWS AT EACH VERSION EQUAL TO customers.
THE SIZE OF THE FIRST WORKING RELEASE. Since the estimate for the total code size in succes-
sive versions is independent of the rate of deletion we
A similar behavior was observed for operating sys- consider that the deleted amount will also be replaced
tem modules, as well as its effect on maintenance by new code. Since the code base grows, more code in
costs [3]. absolute terms is replaced annually as time goes on.
If we call the first working software Version 1, the We also assume that code replacement fractions are
DR rule means the expected growth is 100% from equal for existing code and for code added later dur-
Version 1 to Version 2, 50% from Version 2 to Ver- ing maintenance. We can now combine the effect of
sion 3, 33% for Version 3 to Version 4, and so on, as code growth and code scavenging. If new versions of
shown in the top of Figure 2. The amount of new the software appear every 18 months, then the

70 September 2006/Vol. 49, No. 9 COMMUNICATIONS OF THE ACM

amount of new code in Version 2 becomes about also supports most improvements needed to attract
53%, in Version 3 it’s 71%, and in Version 4 it’s 79%. new customers to an existing product.
The influence of the original code and its IP dimin- We consider below enterprise software, such as
ishes steadily. databases and application tools built on top of them.
Shrink-wrapped software differs in terms of market-
DIMINUTION OF SOFTWARE IP ing, but its IP assessment is remarkably similar. For
To relate code sizes to IP value we observe that the software developed and used in-house benefits are
price of a software product remains approximately case-specific, and much of next discussion dealing
constant, although the code representing that soft- with sales volume, will not apply.
ware grows steadily. We use that observation to allo- Penetration. If the income per unit of software sold
cate income. is constant, then income increases are due to the
Income from a software product
over time. Although the body of Revenue (Erlang) Maintenance revenue Total revenue Revenues - cost
Net sales income Net Maintenance income Net total income Net incomes - cost
code grows over time, the price of a $K Maintenance cost Adj. Maintenance cost to X Adj. Net income - cost to X

unit of software sold tends to stay 8000 Incomes: gross, net, and after cost (-cost)
quite stable, typically increasing less
than the rate of inflation. From the 7000 -cost
Total gross revenue
customer’s point of view a new ver- 6000
Gross sales revenue for Erlang m=12 assumption
sion does not add value, it only pro- 5000
vides the scope, reliability, and ease of net Maintenance revenue
4000 Income <
use that should have been available in unadjusted cost
the first place. Keeping the price sta- 3000 net
ble for a known and reliable product 2000
discourages entry of competition. net -cost
1000
10% x max
P: THE PRICE OF SOFTWARE FOR THE 0

SAME FUNCTIONALITY IS CONSTANT, -1000

EVEN IF IT IS IMPROVED. Maintenance costs
sales < costs
-2000

We now rescale the code contri- Version 1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 end
Years 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
butions based on a constant
expected price to obtain the relative
contributions of the versions to the Figure 3. Revenue growth of unit sales. Sales can increase until its mar-
from sales,
price, as shown in the lower part of maintenance cost, ket is substantially saturated. To reduce uncertainty
Figure 2. The rapid growth of soft- and income, and the size of the candidate market should be estimated
Gio fig approaches.
ware, especially initially, diminishes their combination. using multiple 3 (9/06) Common ways include
the value of the initial IP contribu- using information about a predecessor product, the
tion to the product. number of businesses that need the functionality of
Providers of enterprise software commit themselves the new product and of customers that can afford the
to deliver any further versions of the software to exist- product, the number of a certain type of computer or
ing customers, as long as an annual maintenance fee is operating system in use, and similar bounds. A 50%
paid. Such a scheme is attractive to the customer, who penetration is optimistic; beyond that level distortions
can predict expenses into the future, and the vendor, occur in the market due to the ability to employ
who collects a steady income at low sales costs from monopolistic practices.
efforts that are already required to gain additional cus- A truly useful and well-marketed product can
tomers. Typical rates charged customers for ongoing become rapidly known to the customer community
support are 15% of the original purchase price. Of via the Internet. A software product can be rapidly
that amount a small fraction goes into sales support, delivered to all customers, so that substantial penetra-
the effort to get the customer to upgrade to the new tion is achievable in a short time. If software installa-
version. A larger fraction goes to routine call-center tion requires a major effort, then the sales peak will be
support. The remainder of the support fees, amount- delayed. Further growth can occur if the number of
ing to 6%–10% of the purchase price in every subse- candidate customers grows.
quent year, is available to the engineering staff for the There is some literature on sales expectations [9].
types of maintenance presented earlier. That income Simple models use normal curves to describe the

COMMUNICATIONS OF THE ACM September 2006/Vol. 49, No. 9 71

range of customers from early adopters to broad Businesses still have operational costs to be sup-
acceptance to laggards. A problem with a normal dis- ported by the gross profit: software maintenance,
tribution is that it extends into the past, so the actual marketing, advertising, sales staff, administration,
point where sales commence is undefined. interest for working capital, and so on. Since no rev-
A good fit to actual software sales curves has been enue will be generated without such costs these costs
obtained using Erlang distributions. Just as the nor- reduce the benefits of the initial software. The share-
mal distribution, an Erlang distribution is also con- holders will also want their share of the pie, either as
trolled
Table 1. by Summary
the mean and variance of
of software the data,
benefit but has
factors over adividends or as reinvestments to grow the company.
9-year horizon.
a definite starting point. Fitting provided data yielded The required information is available in the finan-
Erlang parameters from m=6 to m=20. In our sample cial statements of public companies, as annual reports
or published 10-K statements.
Factors Today y1 y2 y3 y4 y5 y6 y7 y8 y9 For a new company one can try
Version 1.0 2.0 3.0 4.0 5.0 6.0 7.0 to find similar businesses and use
Relative size (rule DR) 1.00 1.67 2.33 3.00 3.67 4.33 5.00 5.67 6.33 7.00
Growth R-1 0.00 0.67 1.33 2.00 2.67 3.33 4.00 4.67 5.33 6.00
their ratios. For our example soft-
Replaced (rule GW) 0 0.05 0.10 0.15 0.20 0.25 0.30 0.35 0.40 0.45 ware company we assign
Initial code left 1- Rep 1.00 0.95 0.90 0.85 0.80 0.75 0.70 0.65 0.60 0.55
Fraction old O/R 100% 57% 39% 28% 22% 17% 14% 11% 9% 8% 5% to cost of capital—interest
Unit price ($) (rule P) 500 500 500 500 500 500 500 500 500 500
Units sold 0 1911 7569 11306 11395 8644 5291 2740 1241 503
on loans, no dividends on ini-
Revenue (K$) Us×Up 0 956 3,785 5,653 5,698 4,322 2,646 1,370 621 252 tial or venture funds;
SW share @ 25%×Rev 0 239 946 1,413 1,424 1,081 661 343 155 63 45% to administrative costs,
From initial SW F×Ss
y
0 136 365 400 311 187 93 39 14 5 including sales and distribu-
Discount @15% 1/1.15 1.00 0.87 0.76 0.66 0.57 0.50 0.43 0.38 0.33 0.28
Discounted share Ss/D 0 208 715 929 814 537 286 129 51 18
tion
IP contribution Fi/D 0 118 276 263 177 93 40 15 5 1 25% to software research and
Total disc. share Ds 3,687 K$ development; and
Initial IP value IP 989 K$ 25% to marketing and
advertising.
we use the expected total sales and end when annual Table 1. Summary of
software benefit factors
sales are less than 10% of thetable
Gio best year. Using m=12
1 (9/06) over a nine-year horizon.There can be much variance in
yields the gross sales revenue in Figure 3. these numbers, so data, to be
Sales based on some fixed IP can never continue for- credible, should be aggregated
ever. Eventually the market penetration is complete, over several years and validated by comparison with
and only replacements are sold. The simple Erlang similar businesses.
model shown ignores convoluting factors. For instance, Low capital requirements are typical for the soft-
a product that depends on some infrastructure, say ware industry once a company is operational. Low dis-
Unix, will be affected by the growth or lack of growth tribution costs are also typical for software, especially
of the Unix market. Transborder business is subject to if Internet capabilities can be exploited. To gain visi-
restraints and financial imbalances. bility, however, substantial advertising may be needed.
During the rise of the dot-com business boom many Our sample company invests in future growth.
projections were faulty. Realistic assessments of con- The investors, being stockholders, expect to benefit in
sumer markets could have helped. In a freshman class the long term from increased share prices and defer
of 1998 we considered the expectations for online toy paying taxes. Part of that aspect is captured indirectly
sales and found that by the year 2003 more toys were in the valuation, namely in the increased value of the
expected to be sold on the Web than the total number product due to ongoing maintenance, as described in
of toys being sold, an unsustainable situation. Such the upcoming section on maintenance effect. The
simple checking of limits and identifying inconsisten- software budget is used to improve the current soft-
cies can prevent many problems due to excessive expec- ware and to develop new products, generating new IP
tations. For instance, infrastructure companies like and hence new value to the stockholders, and is a sur-
Cisco and other communication companies that rogate for profit.
accepted orders from enthusiastic dot-com start-ups, In this model we take advertising expenses just as a
could have realized the total equipment being ordered current expense, even though they also increase the IP
was greater than the world could absorb and afford. value of the company. The effects of advertising tend
Expenses attributable to software. For pure soft- to be short-lived, and have less importance than word-
ware companies gross profit is nearly the same as rev- of-mouth recommendations about quality software.
enue from sales. Future allocation. For the valuation, the current

72 September 2006/Vol. 49, No. 9 COMMUNICATIONS OF THE ACM

software development fraction investment is contin- can be challenged and improved in any specific situa-
ued into the future. It is reasonable to apply the same tion. It is also possible to plug multiple assumptions
fraction throughout, unless there is a realistic founda- into the computation to arrive at ranges and explore
tion for higher or lower profit margins in the future. what-if questions. All the values used in the assump-
The following example allocates 25% of the net rev- tions have pragmatic ranges, and their leverage can be
enue to the software IP component, based on a well- explored. For instance, the results would look much
managed company that develops and sells software. better if the unit price is set to say $2,000. However,
To arrive at today’s value of that profit, the benefit such a change means that fewer customers will buy
of future sales must be discounted. We use here a typ- the software and salesmen will have to work harder.
ical software industry discount rate Table
of 15%2. Netperincome
year. including
When we maintenance
analyze IP, for
we the
takeexample
the entireof income,
Table 1.
In high-risk situations such a rate should be higher. and then allocate only 25% to the software, since
there are substantial other costs. If we want to look at
COMBINING THE INFORMATION
We now have estimates of the net Factors in services Today y1 y2 y3 y4 y5 y6 y7 y8 y9
income per unit, the fraction of Est. initial SW cost ($K) 500
IP of the original code remaining Cost of maintenance Cm 67 100 167 233 300 367 433 500 567 633
discounted for lag Cl 82 123 206 288 370 452 534 617 699 781
in each version, and the number SW retained Rev×0.9 y n.a. 860 4,559 9,756 14,478 17,352 18,262 17,806 16,646 15,233
of units being sold for a number Revenue left Rev - Cl -82 832 3,579 5,365 5,328 3,870 2,111 753 -79 -529
of years into the future. Those Maint.revenue Sr -1×0.15 none none 129 684 1,463 2,172 2,603 2,739 2,671 2,497
numbers are combined to pro- Maint.revenue avail 2/3 none none 86 456 976 1,448 1,735 1.836 1,781 1,665
Discounted M.rev. Mr/D none none 98 450 837 1,080 1,125 1,030 837 710
duce the income associated with SW share left @ 25%×Rl -21 208 981 1,797 2,307 2,415 2,263 2.015 1,761 1,532
the initial software into the Discounted to today Sl×D -21 181 742 1,182 1,320 1,201 979 758 576 436
future. The benefit of those 9 years disc. total Dt 7,350 K$
future sales is then discounted
before summing the contribu- Table 2. Net income net income from sales we consider that some such
tions from each year of the life of including maintenance
for the example in
costs are proportional to sales. Making that cost-of-
the software. Table 1. sales Gio
40%table 2 (9/06)
produces the dashed line of net sales
Computing the value of the income in Figure 3. That amount also becomes negli-
software. A spreadsheet provides gible by Version 7.
the best means to summarize the evaluation. Table 1 Effect of maintenance. We indicated earlier that
extracts annual values for our example, starting at a maintenance has a high benefit. Here, we investigate
Version 1.0 and ending with a Version 7.0. New ver- that value. The approach represents a service model,
sions of the software are released every 18 months. For where the relationship of supplier-to-customer is
the sake of presentation we limit software life in Table maintained after the initial sale. The customer will
1 to nine years. The annual IP contribution is that of pay for ongoing maintenance services and always have
the first version, the initial software being valued, an up-to-date product. This income is not part of the
using the diminution shown in Figure 2. valuation of the initial software presented previously,
The result shows that selling 50,000 units of a since it depends on efforts made in future years.
product at a price of $500 over nine years yields a bit Two new financial streams come into play now.
less than a million dollars in terms of IP value dis- While there is income from the maintenance fees, the
counted today. For maintenance and growth $3.687 expenses for maintenance must now also be made
million were kept available. That amount increases explicit: no gain without pain. Initially we must spend
the value of the company, while it also provides jobs much of the software share shown in Table 1.
and societal benefits. Income from maintenance changes the cash flow
Note that the collected revenue was much greater drastically. After year six the income of maintenance
than the value of the IP. Getting that income requires exceeded the income from sales alone. Extending
spending for ongoing software development, market- Table 2 beyond year 9 we find that maintenance rev-
ing, and all the other items within a business. Figure enues remain substantial. Figure 3 plots that effect as
3 displays the results extended up to 19 years. Indeed, lines marked with circles. But to generate those rev-
the sales revenues become negligible after year 9, and enues maintenance of the product is required, which
because of discounting, the IP beyond that point can becomes ever more costly and eventually exceeds the
be ignored. total income, limiting the economic lifetime of the
We made the simplest possible assumptions to software product for the supplier.
arrive at a clear result. All of the assumptions made Income from maintenance. A supplier of enter-

COMMUNICATIONS OF THE ACM September 2006/Vol. 49, No. 9 73

 The goal of this article is to bring together information
from domains that rarely interact directly: software engineering, economics,
business practice, and legal sources.
prise software obtains an ongoing benefit by collect- brings in income. Given a development time of one
ing annual maintenance fees. The software earns year for maintenance code, testing for six months,
maintenance revenue every year, even as sales are and new versions every 18 months the average lag is
made to new customers. Most customers renew their assumed here to be at 1.5 years. That means that
contracts since the alternative—obtaining and effective maintenance costs are increased by a steady
installing new software—is much more costly than 23% to account for the 15% annual discount. Still,
paying a maintenance fee. Table 2 shows the income by the third year the allocated income from mainte-
for 15% annual maintenance fees, based on the initial nance fees is sufficient to pay for all maintenance.
price of enterprise software. We assume that The top curve in Figure 3 shows the total revenue
first-year maintenance is free and that from sales and maintenance, and shows that rev-
90% of customers renew their mainte- enues are still substantial after 19 years, when all
nance contract annually. That are due to maintenance fees. But maintenance
income lags a great deal behind the costs increase, and by year 17 the operation
sales curve. Not all of the income shows a loss. The loss is more pronounced if
from maintenance fees is available we consider the net incomes, shown as dashed
for software. For instance, there must lines. Now we have a loss in year 16, indicated
be a better help desk. For our example, two- by the large square in Figure 3.
thirds of the fee was made available for software. It is wise to stop improving the product at that
But maintenance is easier to sell than new time. Stopping abruptly generates bad press for
software. The dashed line for Net Maintenance a company that sells other products as well.
income assumes that the annual cost-of-sales to Gradually reducing expenses as less
renew a maintenance contract is only 20% of income is generated is wiser. Still, when
the sales amount. customers find out that maintenance is
Cost of maintenance. Now we consider soft- reduced, sales will diminish rapidly and
ware maintenance costs throughout. Mainte- fewer maintenance licenses will be
nance costs are best estimated based on initial renewed. We also show in Figure 3, as
software cost. We assume the initial software cost the dashed lines terminating in a boxed
was $500K, about half of the computed value cross, what happens when we reduce mainte-
obtained in Table 1, leaving the other half to other nance costs 25% per year and suffer a corre-
initial costs. Since we value the workers performing sponding reduction in maintenance contract
maintenance highly, our model assumes a relatively renewals.
high 20% annual cost of maintenance, based on Even with the high cost of long-term ongoing
aggregated software costs. Maintenance costs do maintenance the actual cash flow increases nearly
increase over time. A fair way to estimate that growth three times over the nine-year timeframe. However,
is to make the cost proportional to the total, ever since these additional benefits occur in later years, the
growing code size, as shown in Figure 3. The actual income discounted to today increases less. That
maintenance cost from year 2 to year 7 now amounts income is about twice as much as the income without
to $2,075K. We find that long-term maintenance maintenance revenues.
consumes about 80% of the total cost, a typical per- Model differences. Obtaining a result for the value
centage. of maintenance required many more assumptions
The maintenance costs are borne by the income than the base IP valuation for the initial value of the
from ongoing software sales and maintenance software. We had to consider ongoing costs as well as
licenses. Those costs overlap the costs needed to keep income. To obtain a base for maintenance costs we
the software product viable for sales. Since the bene- also had to guess the initial cost.
fit of maintenance expense is delayed, but paid for The beneficial difference of including maintenance
with current funds, it must be discounted—we must efforts is not captured in a traditional IP valuation.
compute a lag; that is, the delay between the time of Operating in an effective service model also requires
the investment and the time that the investment changes to business practices. Modeling an enterprise

74 September 2006/Vol. 49, No. 9 COMMUNICATIONS OF THE ACM

business with maintenance obeys the appraisal rule interns and recent graduates do innovative work,
that a business should be valued as it actually operates. while rewarding the experienced staff who sustain the
value of their existing products and services in other
CONCLUSION ways, leading to a “gentrification” of maintenance.
Valuation of software is not easy, but is feasible. The The analysis approach shown here cannot deal with
novel contribution of this work is the software the valuation of open source software, which also
growth model, but to assess its effects we must place requires maintenance [12]. Companies that tried to
it in an overall business model that allows a quanti- create a business from servicing open source software
tative assessment of the value of the inherent IP. have had a very difficult time, since reasonable main-
Without such a model unrealistic amortization tenance costs seem extremely high when acquisition is
schedules tend to be used. Many assumptions are nearly free.
required to assess the software-related income and Even though the analyses to value software depend
costs, but making assumptions is inherent in dealing on assumptions that cannot be verified in advance,
with the future. The alternative—remaining igno- having the assumptions stated explicitly and analyzed
rant—provides no guidance. Evaluating alternate allows a discussion of alternatives. Opinions and dis-
assumptions with a spreadsheet based on the model agreements are brought down to a less emotional
provides yet more insights. For instance, determin- level, and will include more organizational and tech-
ing the benefits of maintenance as a service is diffi- nical specifics. c
cult if we can’t even tell what the value of software is
in the first place. Contributing to this work were Treasury economists, Charles Adelberg, Joy
Yen, and Shirley Tessler. Any errors in this article are, of course, my respon-
A specific conclusion is that maintaining software, sibility, but I will not assume any responsibility for business decisions based
although costly, is very worthwhile. Maintenance pro- on application of the presented model.
vides continuing refreshment of the inherent IP. With
high-quality maintenance a company can transform References
A broader version of this article with additional references, software busi-
its business from a sales model into a service model. ness types, and downloadable spreadsheets that can be used to experiment
Service income is attractive to mature companies, with the models is available at infolab.stanford.edu/pub/gio/inprogress.
html#worth.
reducing the need for new products to keep sales high.
To operate in a service model management must 1. Abba, W. Earned value management: Reconciling government and
appreciate the process and motivate software staff to commercial practices. Program Manager 26, 58–69.
2. Basili, V. Viewing maintenance as reuse-oriented software develop-
sustain the value of the product. Everyone must be ment. IEEE Software 7, 1 (Jan. 1990), 19–25.
involved, not just the programmers, but also the staff 3. Belady, L. and Lehman, M.M. An introduction to growth dynamics.
Statistical Computer Performance Evaluation. W. Freiberger, Ed. Acade-
that provides the ongoing intellectual input for the mic Press, 1972.
three types of maintenance presented in this article. 4. Boehm, B. Software Engineering Economics. Prentice-Hall, 1981.
However, maintenance costs eventually overtake 5. Damodaran, A. The Dark Side of Valuation: Valuing Old Tech, New
Tech, and New Economy Companies. Prentice-Hall, 2002.
income. The limit on the life of software is not obso- 6. Glass, R.L. Facts and Fallacies of Software Engineering. Addison Wesley,
lescence, but rather the cost of maintaining ever more Reading, PA. 2003.
complex software [3]. Providing for ease of mainte- 7. Jones, T.C. Estimating Software Costs. McGraw-Hill, 1998.
8. Lev, B. Intangibles, Management, Measurement and Reporting. Brook-
nance in software design and managing maintenance ings Institution Press, 2001.
well should have significant benefits. 9. Mahajan, V., Muller, E., and Wind, Y., Eds. New-Product Diffusion
Models. International Series in Quantitative Marketing. Kluwer, 2000.
Education and technological attitudes favor nov- 10. Pigoski, T.M. Practical Software Maintenance—Best Practices for Man-
elty over maintenance. Typically software engineering aging Your Software Investment. IEEE Computer Society Press, 1997.
textbooks devote less than 1% of their pages to main- 11. Smith, G. and Parr, R. Valuation of Intellectual Property and Intangible
Assets, 3rd Edition. Wiley, 2000.
tainability and maintenance, although they admit that 12. Spolsky, J. Joel on Software. Apress, 2004.
maintenance costs are greater than 60% of total cost.
Most students in computing disciplines graduate
without ever having faced the issue that software must Gio Wiederhold (infolab.stanford.edu/people/gio.html) is an
emeritus professor of computer science, electrical engineering, and
adapt. Students might have had a summer job in a medicine at Stanford University. He is a fellow of the ACM, the IEEE,
company that assigned them to maintenance tasks, and the ACMI.
because the knowledgeable programmers wanted to
Permission to make digital or hard copies of all or part of this work for personal or
move on and do new stuff. It is, of course, an illusion classroom use is granted without fee provided that copies are not made or distributed
that cheap labor reduces the cost, it mainly reduces for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. To copy otherwise, to republish, to post on servers or to redistribute
the benefits of maintenance. Managers bemoan the to lists, requires prior specific permission and/or a fee.
high cost of maintenance, since they are not clear
about the benefits [12]. It would be better to let © 2006 ACM 0001-0782/06/0900 $5.00

COMMUNICATIONS OF THE ACM September 2006/Vol. 49, No. 9 75