Licensing Software for Mutual Success

Most enterprises make extensive use of open-source software. Many are attracted by the price: free. Free from the perspective of some people, anyway. Most enterprises also purchase a lot of commercial software and services. I want to explore how licensing terms often discourage using the software most effectively—encouraging suboptimal decisions that do not promote the success of the customer or the vendor—and explore an alternative model for licensing software that attempts to align these interests.

Pricing models for software and services can create very perverse incentives. In the early days of home Internet, people were often eager to switch from plans where they paid based on their usage—megabytes uploaded and downloaded—to unlimited plans, even though these plans were often more expensive. Paying per megabyte encouraged conservation and limited use and utility. Even if an unlimited plan cost more, it put an upper-bound on the price and encouraged people to use the Internet without worrying about the marginal cost of sending an email, reading an article, or watching a video.

Commercial software is usually licensed based on a metric like the number of CPU cores, the number of servers, the number of clusters, or the number of clients. These licensing models are outdated when applied to cloud-native architectures that embrace containers, services with a single responsibility, isolation, dynamic scaling, and shared infrastructure. They do not necessarily support canary releases, A/B testing, or architectures for high-availability. Instead, these licensing models encourage you to constrain your use of the software in order to reduce costs. For example, rather than having two services, each one with a clearly defined responsibility, licensed as two separate clusters, you might consider combining them, in order to reduce licensing costs. Or, constrained by cost, perhaps you forgo developing the second service altogether, limiting experimentation, innovation, creativity, and optionality. This also limits the revenue potential for the vendor. If you were allowed to use their software more liberally, you might discover a unique way of using it for which you are perfectly happy paying them more money.

I worked at an industrial software company for many years. The flagship product was a time-series historian that was popular in manufacturing, oil and gas, and the generation, transmission, and distribution of electricity, among other industries. The primary licensing model was to price the software per time-series. A single time-series would be something like a temperature, pressure, flow rate, frequency, or power measurement from a specific piece of industrial equipment. The more series that you used, the higher the licensing fees. The reasoning, understandably, was that the more series you used, the more value you derived from the software—you collected more measurements, monitored more assets, performed more calculations, and gained more operational insight.

This licensing model encouraged many customers to only measure what they deemed essential. This might sound like a good thing, but especially in complex systems, you do not know a priori what measurements will be valuable for later analysis—you need to take a systems view and a multivariate approach. Sometimes the per-series licensing model encouraged customers to do extraordinarily silly things, like combining two time-series into one, just to reduce licensing costs.^[1] As the vendor, it had the undesirable effect of focusing the conversation around economizing series, rather than elevating the discussion to focus on the value that the software could provide to the customer. As the vendor, you want to be having conversations about value with your customers. Conversations about counting series, CPU cores, or servers are a distraction.

One of the original employees of this company—a person very adept in managing customer relationships and someone that I learned a great deal from—was of the philosophy that you should record all measurements, because you never know what questions you might want to ask of the data in the future. It is easy to appreciate that customers who followed his advice had greater insights, solved more problems, and derived greater value from the software, relying on it more and more.^[2]

One way vendors try to get around suboptimal use of software is to structure license agreements based on T-shirt sizes—tiered licensing—small, medium, large—where you pay a fixed cost, as long as you remain within the fixed size. This model encourages better marginal decisions, at least until you approach the threshold from one size to the next, when it invites all of the same dysfunctional decisions, perhaps even more so.

An innovation the company I worked at had was to provide the option to license the software based on a metric that was meaningful to the success of the customer, rather than some arbitrary metric like the number of time series, CPU cores, servers, clusters, or clients. For a manufacturing company, this metric might be units produced annually; for a shipping company, it might be net-weight shipped annually; for a producer of electricity, it might be megawatts generated annually. Whatever the measure, for a public company, it would typically be something reported on the earnings report and be a measure that was critical to the success of the business. Otherwise, within the licensing agreement, the software was all-you-can-eat, with very few restrictions on the extent of its use.

With this model, the more successful your business is, the more that you pay. But you only pay more if and when you are successful. This model aligns the interests of the customer and the vendor, and it encourages a more collaborative, mutually beneficial, and sustainable long-term relationship. It also protects your business against unreasonable cost escalations—at least within the terms of a long-term agreement—where you start using commercial software at a teaser rate, only to become critically dependent on it when the vendor looks to negotiate much more lucrative terms. If you are pricing based on measures like units manufactured, net-weight shipped, or megawatts generated, it should lead to more predictable and sustainable pricing structures.

Now that I no longer work for a software vendor, I appreciate this licensing model even more. It is my preferred way to license commercial software, since it does not arbitrarily limit engineering decisions and allows me to take a more creative and experimental approach. Innovation can precede revenues, before having to realize the full licensing costs. If my business is successful, your business will be successful, and we will both benefit.

Consider the case of running a primary and a backup database-cluster to provide high-availability and disaster recovery for a critical service. Most vendors are happy to provide licensing for development or test clusters at minimal or no cost, however, they usually want to extract a lot of money for licensing a backup production-cluster. The reasoning is that you are deriving a lot of business value from using their software to provide a higher service-level. But the vendor is not doing anything to provide this additional availability automatically. In addition, if the vendor looks at costs holistically, there is a lot of value in this arrangement for them, too.

First, with a backup database cluster running in parallel, if I run into a critical production issue, I can swap operation to the backup cluster and I can address the problem in a more relaxed manner, likely during business hours. The alternative, with a single cluster, would be a critical, 24x7 support call with the vendor, with everyone scrambling, stressfully, to get the production issue resolved as soon as possible. Second, a secondary cluster provides operational flexibility and reduces risks in applying patches, upgrades, or configuration changes. When your customers are running a recent version of your software—rather than a buffet of old versions with known issues, security vulnerabilities, and different operating procedures—it is cheaper and much easier for you, the vendor, to support. Finally, a second cluster can provide a lot of insight into operational issues for the vendor, since customers can often compare and contrast the workloads on the two clusters, experiment with different configurations, and gain insights that would not otherwise be possible. These benefits can lead to reduced costs and greater insights for the vendor, a better experience for the customer, and a significantly more successful and productive relationship.

Maintenance and support contracts cannot necessarily follow this all-you-can-eat software licensing model, since they involve pronounced costs in terms of people and time. However, a complementary maintenance and support model that also encourages helping the customer succeed, upfront, is the best one, in my opinion.

It is interesting to consider service providers, like the major cloud vendors, where basically the only pricing model is based on usage—paying per request, per megabyte, per unit of time, and so on. There are certainly a wealth of creative pricing structures offered by these vendors—per-second billing, archival storage, spot-pricing, preemptable workloads, sustained-use discounts, discounts for upfront payment and resource reservations—but all of these pricing models still boil down to usage, in one form or another. They encourage using less, in order to reduce costs.^[3] I find it interesting to imagine how service providers might model pricing to align with the success of their customers. Generous free-tiers and try-and-buy models certainly help many customers explore their options and get started without incurring huge costs, but it will be interesting to see if more creative and supportive pricing models evolve over time, as more and more enterprises leverage these services.

The licensing model that I have described is not without its own set of challenges. It may not be attractive when a business anticipates tremendous growth. The business many want to add some time-delay to vendors capitalizing on its growth and prefer fixed-cost licensing agreements in the short-term, in order to control costs and free up capital to invest elsewhere. Furthermore, at scale, this model needs some adjustments that cut both ways. If you are selling a large number of units for thousands of dollars each, and the vendor is only making fractions of a dollar per unit, the vendor may feel like they are getting the short end of the stick. For example, if you sell one million units at $1,000 each, that is one billion dollars in revenue for you. If the vendor only gets 50 cents per unit—essentially a rounding error of the $1,000 per-unit price—they may feel they deserve a bigger piece of the pie. But viewed from the customer's perspective, 50 cents per unit adds up to the healthy sum of $500,000. Adopting the vendor's standard, off-the-shelf per-core, per-server, or subscription pricing-model could easily reduce this cost by an order of magnitude. I still like a licensing model that encourages a partnership, aligning incentives for both the vendor and the customer, but at scale, this model may need to incorporate tiered pricing in order to keep it attractive.

If you are a vendor licensing commercial software or services, rather than pricing by indirect measures like CPU cores, servers, or clusters, consider a licensing model that is based on a metric that will see you succeed if and when your customer succeeds. Rather than counting arbitrary resources, elevate the discussion to a conversation about the value that your software can provide to the customer. If you are a customer, ask your vendors to price the software in this manner and see how receptive they are to it. I think the vendors that are open to this approach will be the most engaged in your success, the most enjoyable to work with, and, in the end, the most successful.