Common Software Business Models

The most common software- related business models make money by

  • Providing unfettered access to or use of the application for a defined period of time

  • Charging a percentage of the revenue obtained or costs saved from using the application

  • Charging for a transaction, a defined and measurable unit of work

  • Metering access to or use of the application, or something the application processes

  • Charging for the hardware the application runs on or hardware intimately associated with the application, and not the application itself

  • Providing one or more services that are intimately related to application operation and/or use

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.

Will That Be an Application, Suite, Bundle, or Feature?

Companies that offer more than one product often try to create synergies around their various product lines. One way of doing this is to associate a set of products as a "suite" or "studio." To be effective, the products the suite comprises should work together and should address some aspect of a common problem domain. Organizationally, it is best if there is a separate marketect in charge of the suite, whose primary job is to work with the marketects of each suite product to make certain the suite is a good value for customers.

A bundle is a simpler concept than a suite and is usually based on a set of products that may have no special relationship to each other, may not interoperate , and may even be normally targeted at different market segments. There may be a separate marketect in charge of a bundle. Ultimately, the marketect must answer the questions associated with creating a suite or a bundle, or with marketing a feature or an application.

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:

  • A complex system may have multiple business models. The "base" system might be transaction-fee based while additional "optional" modules might be annually licensed. The central business model should be congruent with the value received from the customer by the generic and expected product. The augmented product may benefit from different licensing models.

  • Business models are often coupled with one or more field-of-use license restrictions, which constrain where, when, and how the software can be used. Common field-of-use restrictions include single computer, a single site (called a site license ), or one or more geographies (which export restrictions may require).

  • Field-of-use restrictions work in conjunction with the core business model to create more total revenue for a company. Consider an annual license that is restricted to a single computer. If the licensee wishes to use the software on another computer, he must obtain an additional license, thereby driving more revenue. Field-of-use restrictions are another aspect of the licensing model, much like the "right to upgrade" or the "right to receive technical support." For consistency in contract language and in enforcing your licensing model, it may help to convert a field-of-use restriction to a right (or entitlement )you have the right to use this software on a designated computer, or you have the right to use this software on any computer in your company.

  • All of the business models associate some period of time with their use. This period is defined in the license model. Common time periods include months, quarters , and years .

  • The licensing model may also define how and when a customer must make payments as a way of extending a given business model to a new market. For example, a service based on a monthly payment originally created for the small to medium business (SMB) market and requiring a purchase order might have to be augmented with the ability to accept credit cards to reach the small office/home office (SOHO) market.

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.

Per-User Licenses

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. [1]

[1] I'm intentionally simplifying this example to illustrate a point. In reality, the price of a call is determined by many complex factors, including, but not limited to, tariffs and the time of day of the phone call. The telecommunications industry is a great case study of how both the marketect and a tarchitect must know the subtleties of the legal issues in creating the business model.

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.

Sounds Great, But What Do I Charge?

A business model defines how you will charge a customer for your products and/or services but not how much. A pricing model defines how much. Transaction fees, for example, can be just a few cents to many millions of dollars depending on the nature of the transaction! If your business model is based on access to the software, the associated pricing model could be a one-time payment based on the specific modules or features licensed (a "menu" approach), or it could be a set fee based on the annual revenue of the enterprise.

Pricing a product or service is one of the hardest of the marketect's jobs. Charge too much and you face competition, lower revenue (too few customers can afford your product), and slow growth. Charge too little and you leave money on the table. While a detailed discussion of pricing is beyond the scope of this book, here are some principles that have worked well for me.

  • Price should reflect value. If your customer is receiving hundreds of thousands of dollars of quantifiable benefits from your product, you should receive tens of thousands of dollars or more. From the perspective of your customer, price isn't affected by what the product costs but by what it's worth.

  • Price should reflect effort. If your application requires a total development team of 120 people, including developers, QA, technical publications , support, product management, marketing, and sales, then you need to charge enough to support them. From the perspective of your employer, if you're not going to charge enough to be profitable, your product will be shut down. And it should be. Either it isn't providing enough value or the value it provides costs too much to create.

  • Price should support your positioning. If you're positioning yourself as "premium," your price will be high. If you're positioning yourself as "low cost," your price will be low.

  • Price must reflect the competitive landscape. If you're the new entry into an established market, a new business model or a new pricing model may win you business. Or it may simply confuse your customers. If it does, you're probably going to end up switching to a business model that your customers understand. Either way, understanding the business models of your competitors will help you make the right initial choice and will help you quickly correct for a poor one.

  • Pricing models should not create confusion among your customers. I realize that this can be difficult, especially when you're creating a system with a lot of options. Find ways to reduce the complexity of the menu approach by offering bundles, or just plain simplify your offerings.

  • Pricing models should reflect market maturity. If you're in an emerging market, you may need to try several different pricing models before you choose the one that works best. Be careful with your experiments because later customers will ask earlier customers how much they've paid. Note that you can only do this if you have a method for tracking and evaluating the model performance. This can be a tarchitectural issue, in that you may need your software to report certain information to back-office systems when it is installed or used.

  • It is usually harder to raise prices than to lower them for the same product. If you start too low and you need to raise prices, you may have to find a way to split and/or modularize your offering.

  • Pricing models should reflect your target market. Selling essentially the same solution at different price points to different markets (e.g., the student or small office version) often makes good sense.


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.

Open Source Does Not Mean Free

Sleepycat Software has married a traditional time-based usage business model with an open source certified licensing model in way that drives widespread adoption while still making money. The way it works is that Sleepycat provides its embedded database system, Berkeley DB, as an open source license. The terms allow you to use Berkeley DB at no charge, provided that you give away the complete source code for your application under an open source license as well. This is a great example of the viral element of open source licensing.

Many people who use Sleepycat can do this. Proprietary software vendors aren't able to offer their software under the open source license, so Sleepycat sells them a different license for Berkeley DB that permits them to use it without distributing their own source code. This is where the business model comes into playthe way that Sleepycat makes money is very similar to standard licensing models.

Sleepycat can use this approach because the proprietary vendor must link the database into their application and because Sleepycat owns all of the IP associated with the code. The linking process gives Sleepycat leverage to impose licensing constraints, and the ownership of the IP means that Sleepycat can control license terms as they choose. According to Michael Olson, the CEO of Sleepycat, the marriage is working quite well, as Sleepycat has been a profitable company for several years, and is yet another lesson in the benefits of separating your business and license models.

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
Year: 2005
Pages: 202 © 2008-2017.
If you may any questions please contact us: