The most common software- related business models make money by
Traditional software publishers or independent software vendors (ISVs) rely heavily on the first four models. The other models may be associated with an ISV or may be based on an open -source licensing model. For example, you can't sell Apache, but you can certainly base your business model on installing, configuring, and operating Apache-based servers.
Before you read further, go back to the beginning of this list and replace the word application with feature. Applications are collections of features, each of which can be offered under a different business and licensing model. Thus, for example, you can provide unfettered access to the base application for an annual license fee but charge a transaction fee for invoking a special feature that produces a defined and measurable unit of work. Defining this mix is a key responsibility of the marketect.
The more sophisticated business models are usually associated with enterprise applications, although this is continually changing as the technology to enforce license models matures. Metering is a good example. Many enterprise applications meter by concurrent user. In consumer applications, you might want to meter by the amount of time the user has been accessing your application, but this requires sophisticated technologies, including a reliable way to capture usage data. As these technologies mature, you will find these business models offered wherever they increase business!
Let's consider each of these business models in greater detail, keeping in mind the following points:
Time-Based Access or Usage
In this model, the licensee can use the software for a well-defined period of time, such as when you purchase an operating system. What is really happening is that the operating system publisher, or its agent, has granted you the right to use the operating system, typically on one computer, for that time. Other rights and restrictions will be defined in the license model, but the core business model is based on accessing or using the software (you pay to license the software so that you can use it).
Common time periods for time-based access or usage include the following.
The licensee is granted a license to use the software in perpetuitythat is, forever. Upgrades or updates are not usually included and instead are separately priced. Bug fixes or patches may be included as part of the original fee, or you may be required to pay a maintenance fee (typically ranging from 15 percent to 30 percent of the initial license fee). Be very careful of perpetual licenses, as they often increase total support and maintenance costs (unless you're careful, you may have to support every version forever! ).
Despite the potential drawbacks of perpetual licenses, they are surprisingly common and often required in many markets. Consumer software; common productivity tools, such as word processors or presentation software; operating systems; and many enterprise applications are based on them. Perpetual licenses may be required if you're providing a system or technology that may be embedded within other systems. Examples range from the runtime libraries provided by programming language vendors (e.g., the C runtime library) to systems that may become components of hardware devices or information appliances.
The software can be accessed or used for one year from the effective date of the license. The effective date can be defined as the time the license is granted, the time the software is installed, or the time the software is first used. Annual licenses often include software updates or patches. They may or may not include other services, such as technical support or consulting fees, and they are usually renewable. Renewal may be automatic, and it may be priced differently from the original annual license.
The difference between a perpetual license with an annual maintenance fee and an annual license is subtle but important. In the case of a perpetual license, the maintenance fees are added on as a way of enticing the licensee to pay for additional services, such as bug fixes or new releases. In the case of an annual license, if the licensee hasn't paid and continues to use the software, it is in breach of the license. You will ultimately have to decide how you want to enforce license terms and conditions, a topic explored in greater detail later in this chapter. Annual licenses are common in enterprise-class systems.
Although perpetual and annual licenses are the most common predefined time periods, there is nothing that prevents you from defining other periods (e.g., nine months) or a collection of times when the software can be accessed (e.g., Monday through Friday from 8 to 5). The hard part is defining one that works best for your target market and making certain you can appropriately enforce the business model and license terms (which market segment would find sensible a nine-month period or only accessing software Monday through Friday from 8 to 5?).
Here are a few additional time-based usage models.
A rental is a time-based model in which the time allowed for use is set when the license is granted. In reality, it is just an annual license with a different term (or an annual license is just a rental of one year). Rentals are becoming increasingly popular in certain industries, including software test automation and electronic design automation (EDA). As license management technology matures, I predict that rentals will reach all market segments and that we will be able to rent just about every application available.
The business motivations for rental are compelling. For one, a rental allows you to reach a new market. Suppose, for example, that you rent a high-end, professional video editing system for $50,000 for a single-user annual license. One way to reach the home user market is to create a simpler version of this system, with fewer features. Another way is to offer the system as a rental (say, $100 per hour ). For the user who has learned the system at work but wants to use it at home, the rental price might be a real bargainshe already knows how to use the application, so why go with anything else?
Key issues that must be resolved with a rental model include specifying when the rental period begins (when you purchase the license? install the software? start using the software?); determining how the software should respond when the rental is finished (will the program stop working entirely, or will you give the user some kind of grace period so that she can save her work?); and pricing (if you can obtain a perpetual license for a graphic design package for $2,995, what is the cost for a one-hour rental? a one-day rental?).
At the other end of the spectrum is a subscription, in which customers pay a periodic fee to access the software. A subscription is like a rental or an annual licenseall that differs is the terms and rights. For example, a rental may not include the right to receive upgrades or patches. Most subscriptions and annual licenses do include this. A rental and a subscription may include technical support, while in many cases you must purchase an additional contract (which can define varying kinds or levels of support) with an annual license. Because subscriptions are often associated with some backend service, the license models that define them are relatively easy to enforce. Simply cut off access to the backend service!
Pay after Use
An interesting question arises in any time-based usage model: What happens when the user accesses the application after the approved period of time? How you answer this question can make or break your relationship with your customerand your bank account. At one end of the spectrum is absolute enforcement of a business model with no grace period: When the term is finished, the software becomes inoperable. This very severe choice is simply inappropriate for most target markets. An emerging business model charges the customer after he has used the software by keeping track of how long he has used it. This model places a host of complex demands on the tarchitecture (see below), but it does help ensure that the company is receiving every dollar it can from the use of its software.
An analogy is a car rental. You're typically charged for each day you rent the car, with strict definitions as to what constitutes a day. If you go beyond the original contract, the car company continues to charge you (they have your credit card on file, and the rate that you'll be charged is predefined in the contract). This pay-after-use business model will become more popular as the relationship between business models, licensing models, and billing systems matures, and as marketects learn to use these new capabilities to create compelling "pay-after-use" solutions.
A special category of software that uses time-based access or usage licenses is applications designed to work on a single personal computer, workstation, or handheld device. As a group , these licenses are often referred to as per-user, and often cost less than $500. Per-user licenses work great when the publisher is licensing one copy to one user but not so well when a publisher is trying to sell 500 or 5,000 licenses to an enterprise.
To address this issue, most major software publishers have created volume licensing programs to more effectively reach enterprises (businesses, charitable organizations, academic institutions) that license more than one copy of the same software. Volume licensing programs are not fundamentally new but, instead are sophisticated pricing models based on an access- or usage-based business model. They offer enterprises a way to acquire multiple licenses of a given program, usually at a discount. The more copies licensed, the greater the discount.
In a transactional volume licensing program, each product is associated with a certain number of points. A high-end, expensive product may be worth five points; a low-end, inexpensive product, one point. As an enterprise creates a purchase order (500 licenses to this software, 230 licenses to that software) a point total is dynamically computed. Applicable discounts are calculated based on the total points as specified by the transaction.
In a contractual volume licensing program, the enterprise estimates the number of licenses they will need for a projected period of time and commits to acquiring at least these licenses by the time specified in the contract. The commitment to purchase a minimum number of licenses entitles the enterprise to a discount. Bonus discounts may be allowed if additional licenses are acquired , and penalties may be assessed if the customer does not license enough.
Both transactional and contractual licensing programs are highly regulated by the companies that offer them. Consider them whenever you sell multiple "copies" of the same software to one enterprise. Such licenses are more appropriate for applications that can be used in the enterprise context ( games are probably not a good choice for a volume licensing program). You may not want to offer a personal finance program as part of a volume licensing deal, largely because the target market will be a single user on a single computer. That said, marketects should be aware of the benefits that a volume licensing program can provide to their customers and their product lines.
Another category in which time-based access or usage is dominant is in the OEM (original equipment manufacturer) or royalty market. The business model is access to the software. The pricing model is whatever makes sense (in the case of an OEM) or a fairly defined royalty.
Transactions are defined and measurable units of work. Business models based on them associate a specific fee with each transaction or a block of transactions. A transaction can be surprisingly simple or maddeningly complex. For example, it can mean executing the software. This is common in a business model known as "try and die," in which you can execute the software a predefined number of timessay, fivebefore it becomes inoperable. I've worked on systems in which a transaction was distributed among multiple servers; the business model was based on charging the customer whose "root" server initiated the transaction.
Fees may be calculated in many different ways. I've worked on systems based on flat fees (a fixed cost per transaction), percentage fees (a percentage of some other calculated or defined amount), sliding fees (the cost per transaction decreases as certain volumes are realized), or processing fees, in which the work to perform the transaction is measured and the customer is billed accordingly (e.g., a simple transaction that could be computed with few resources costs less than a complex transaction that required many resources).
There is nothing about a transaction-based model that requires all transactions to be the same size, duration, or amount. Indeed, such differences are the foundation of many business models, and you can use them to create different pricing structures. For example, in the telecommunications industry a phone call is a transaction, the duration of which determines the price. 
Transaction-based business models are found almost exclusively within enterprise software. Creative marketects know how to define a transaction and construct a transaction fee that works best for their target market. It is imperative that the tarchitect understand both the legal and the business-model transaction definition.
Metering is a business model based on constraining or consuming a well-defined resource or something that the application processes. A constraint model limits access to the system to a specific set of predefined resources. A consumptive model creates a "pool" of possible resources that are consumed. The consumption can be based on concurrency, as when two or more resources simultaneously access or use the system, or on an absolute value that is consumed as the application is used. When all of the available resources are temporarily or permanently consumed, the software becomes inoperable. Many successful business models blend these concepts based on the target market. Here are some of the ways this is done.
Concurrent Resource Management
This business model is based on metering the number of resources concurrently accessing the system, with the most common resource either a user or a session. The business model is usually designed to constrain the resource ("a license for up to 10 concurrent users"). Both user and session must be defined, because in many systems a single user can have multiple sessions. The specific definition of a resource almost always has tarchitectural implications; managing concurrent users is quite different from managing concurrent sessions, and both are different from managing concurrent threads or processes.
Like transaction fees, concurrent resource business models have a variety of pricing schemes. You may pay less for more resources, and you may pay a different amount for a different resource. Concurrent resource models are almost exclusively the domain of enterprise software.
Identified Resource Management
In this model, specific resources are identified to the application and are allowed to access the system when they have been properly authenticated. The constraint is the defined resources, the most common of which is a named user, that is, a specifically identified user allowed to access the application. Identified resource business models are often combined with concurrent (consumptive) resource business models for performance or business reasons. Thus, you may create a business model based on any 10 out of 35 named users concurrently accessing the system or any 3 out of 5 plug-ins concurrently used to extend the application.
The concept of a user as the concurrent or identified resource is so prevalent that marketects should be alert to the ways in which they can organize their business model around users. One common way is to classify users into groups, or types, and separately define the functions and/or applications that each group can access.
The idea is analogous to how car manufacturers bundle optional/add-on features in a car and sell it as a complete package (the utility model versus the sport model). As a result, it is common in concurrent or named user business models to find defined user types (bronze, silver, or gold, or standard or professional) with specifically defined functionality associated with each (e.g., a concurrent gold user can access these features ).
The administrative burden of this approach can be overwhelming for corporate IT departments. To ease it, try to leverage existing directory or user management infrastructures , such as any AAA (access authentication authorization) or LDAP (Lightweight Directory Access Protocol) servers that may be installed. These systems are designed to assist IT in capturing and managing these data.
Consumptive Resource Management
In this model, you create a specified amount of a resource and consume that amount once when the application is invoked or continually while it is running. Unlike a concurrent model, in which consumption varies based on the specific resources simultaneously accessing the system, a purely consumptive model expends resources that are not returned.
Consider time as a consumptive resource. In this approach, you define a period of time (e.g., 100 hours or 30 days) and provide the user with a license for it. As the software is used, it keeps track of the time, "consuming" the designated value from the licenses. When all of the allotted time has been used the software becomes inoperable. Key issues that must be resolved in this approach include the definition of time (actual CPU time, system-elapsed time, or other), the manner in which the software will track resource consumption (locally, remotely, or distributed), and the granularity of the time-based license ( milliseconds , seconds, days, weeks, months, and so forth).
More generally , it is possible to define an abstract resource and base your business model on metering it. Suppose you have an application for video publishing with two killer features: the ability to automatically correct background noise and the ability to automatically correct background lighting. You could define that any time the user invokes the background noise correction feature they are consuming one computing unit while any time they invoke the background lighting correction feature they are consuming three computing units. You could then provide a license for 20 computing units that the user could spend as she deems appropriate.
Consumptive resource models can underlie subscription-based service modelsduring each billing period (e.g., monthly), for a set fee, you get a predefined number of resources; when the resources are consumed, you can purchase more or stop using the application, and any not consumed are either carried over to the next billing period (possibly with a maximum limit, like vacation days at many companies) or lost forever. This is similar to the access-based subscriptions, except that you are metering and consuming a resource. The difference may be fine-grained, but it is worth exploring the potential benefits of each type because you may be able to access a new market or increase your market share in a given market with the right one. In addition, both models make unique demands on your tarchitecture, so the tarchitect will have to know the difference.
Consumptive models have another critical requirement often overlookedreporting and replenishment. It must be extremely easy for a user/administrator to predict how much an operation will "cost" before she decides to spend, the rate at which spending is occurring, and when the rate of spending will exceed the allotment for the month or a resource budget is nearing depletion. Because customers will often overspend, it should be painless to buy more. No one will blame you if they run out of a critical resource on Friday afternoon at 6 P.M. Eastern time, just before a critical big push weekendespecially if you warned them yesterday that it would happen. But they will never, ever forgive you if they can't buy more until Monday at 9 A.M. Pacific time.
Hardware-based business models associate the amount charged for the software with some element of hardware. In some cases the software is free, but is so intimately tied to the hardware that the hardware is effectively nonfunctional without it. A more traditional approach, and one that is common in business applications, is to associate the business model with the number of CPUs installed in the system. As with all business models, the motivation for this "Per-CPU licensing" is money.
Say an application has been licensed to run on a single machine. If the performance of the machine can be substantially improved simply by adding additional processors, the licensor (software publisher) stands to lose money because the licensee will just add processors without paying any additional license fees! If this same application is licensed on a per-CPU basis, then adding more processors may improve performance but the licensor will get more money for it.
Hardware based business models can be based on any aspect of the hardware that materially affects the performance of the system and can be enforced as required to meet business needs. Per-CPU or per expansion card are the most common, but you can also use memory, disk storage (e.g., redundantly mirrored disk drives might be charged twice), and so forth. I wouldn't recommend basing the model on the number of connected keyboards, but you could if you wanted to.
Service-based business models focus on making money from one or more services, not from the software that provides access to them. My favorite example is America Online. AOL doesn't charge for the software; they charge a monthly subscription fee for access to a wide range of services, including e-mail, chat, and content aggregation.
Service-based business models are often used with open source licenses. Examples here include providing assistance in the installation, configuration, and operation of an application or technology licensed as open source or built on open-source software, creating education programs (think O'Reilly) and custom development or integration services.
Creating a service-based business model through open source software (OSS) licensing is a creative approach; however, as of the writing of this book there are no provably sustainable, long-term successful open-source software service business models. This is not an indictment of OSS! I'm aware that most of the Internet runs on OSS, and many companies have very promising service-based business models related to it. I'm merely acknowledging that the market is immature and so such models have yet to be proven. Therefore, any marketect approaching his or her business through OSS should proceed with caution.
Revenue Obtained/Costs Saved
Another business model that is common in enterprise software is a percentage of revenue obtained or costs saved from using the application. Suppose you've created a new CRM (customer relationship management) system that can increase sales to existing customers by an average of 15 percent. You may consider charging 10 percent of the incremental revenue, provided that the total dollar amount is large enough to justify your costs.
Alternatively, let's say that you've created a new kind of inventory tracking and warehouse management system targeted toward small companies ($5M to $50M in annual revenue). Your data indicates that your software will save these companies anywhere from $50K to $1M. A viable business model may charge 15 percent of the savings, again provided that the total dollar amount is sufficiently large.
In choosing these models you have to have a rock-solid analysis that clearly identifies the additional revenues or savings. If you don't, no degree of technical skill in the development team will help the architecture become successful. The fundamental problem is that the data on which these models are based are extremely subjective and easily manipulated. You might think that your new CRM software generated $100,000 more business for Fred's Fish Fry, but Fred thinks it's the spiffy new marketing campaign that Fred, Jr., created. Result? You're not going to get paid the amount you think you've earned.
Enterprises also appear to be more resistant to models based on cost savings. I once tried to create such a model. Even though we had a very solid ROI, the model didn't work and we switched from costs savings to transaction fees. Percentage of revenue obtained or costs saved are also unpopular because they make customers track how much they should pay. It is usually much easier to determine how much a customer should pay in the other business models.