Mr. Customer, our price is $13,349 per floating development seat. Larger teams need more support, so we charge an additional 20 percent for maintenance and support. Runtimes start at $800 per core and decline through a series of levels with volume down to a few dollars each. Would you like the optional tool package? Great, that will be $7,500.
It sounds well thought out and justified. Doesn't it? It is thought out, but sorry, it's based on fiction.
Software pricing has always been controversial. Moreover, as the evidence mounts that open source does not control costs, it has become even more critical. How much is software worth? Who should pay for it? What's fair? Should vendors charge per floating license, per user, or for support only? And what about, runtime royalties?
Many business models have evolved over time. Any successful policy must accomplish one key goal: the revenue must cover the costs--and then some--of providing the software. However, nobody seems to be coming right out and revealing "the dirty little secret of software pricing." And not understanding that secret costs people, companies, and governments a lot of money.
As a long-term vendor of embedded infrastructure software, I feel it's time everyone knew. You see, the secret is (shhhhh!):
Software pricing today makes no sense. Vendors make it all up. The real goal is to charge in proportion to how much money you have.
All the policies are just ways to approximate this rule. The best pricing plans take any metric of a project that correlates to the money involved and charge for that.
Why is this? Partially, it's because there's a fundamental business conflict. Software costs a ton of money to produce. Once done, the incremental cost of another customer is very low. Users want to pay that low incremental cost and vendors need to cover the entire cost. This gap must somehow be bridged, and positioning that bridge is not trivial (Fig. 1). The two natural arguments are about cost to the vendor and value to you.
Figure 1. The gap between the vendor's real software cost and the customer's incremental desires cannot be judged. Justification attempts fail.
Let's first look at cost.
Software is a strange beast. It costs money to develop and maintain. It costs even more money to find and match people to usage; marketing, sales, and presales support outweigh engineering. It costs nothing to produce and ship. And, it costs nothing to provide to everyone. It does cost, however, to help people use it once they start. And, it takes an ongoing investment to keep it current and on track. Development cost is important, but should not be dominant.
Controlling Development Costs
Although they are a small part of overall software costs, most cost analyses focus just on engineering development costs. Even within engineering, the biggest cost is actually "maintenance," or keeping the code base current. "Maintenance" here is in quotes because the line between development and maintenance is vanishingly thin. Good software evolves through a series of versions.
Given that, the real driver of engineering cost is the imperative to keep a single code base. Splitting--copying the source and developing a "branch"-- is orders of magnitude easier than merging. In fact, merging is so hard that an unmanaged branch is almost impossible to merge. Ever. Each branch costs about the same to maintain, so the split doubles costs. Uncontrolled version explosion is death. Any policy that does not recognize that is doomed to failure.
This is not always obvious. For instance, government models don't account for it. Source "repositories" come and go, rights are demanded, open source is encouraged, all in the name of having free access to IP. Yet software costs go up and up and up because cheap software is continuously maintained software. Cheap software has a trained, stable team. And cheap software has a single code base. If you check out the source and modify it, you just bought an expensive branch. Unsupported source with no team and no version maintenance is a first-class ticket to increased engineering hours. Repositories offer only the false economy of letting integrators compete for those hours, thus lowering rates. But, every new team and every new version is very expensive.
Simply put, the sole imperative to control software cost is to establish a stable team working on a single code base. Every successful software model has that as its core. More strikingly, this is also the main source of excellence in software. Great, inexpensive software is written by stable teams with controlled code.
This fact also explains the unmet promise of open source "community development." At least for emerging products, there is no stable external team. It can work for mature technologies with huge user bases, or those maintained by users. But coordinating one code base across the diverse team is inefficient. Long term, efficiency matters. So, the industry ends up with "flavors," each with a single supporting organization.
Real costs and cost justifications
Maintaining an engineering team, figuring out what code that team should develop, telling the world what the code does, and then matching the code's solution to customers dominate real costs. These responsibilities require a significant ongoing investment in engineering, support, product management, marketing, sales, and services.
Unfortunately, you can't charge customers for that. Customers demand justification for what their spend. Accountants want countable beans. What's a vendor to do? They often strive to bridge the gap by pricing based on some incremental cost metric, but this is fundamentally impossible. Thus, we jump off the real-cost bridge onto the very slippery slope of incremental cost justification. Here are some common explanations:
- Everyone has to pay for support. This is a common example of questionable cost justification. Companies claim that you pay support fees for everyone because larger teams generate more support load. That sounds reasonable, but it's not true. In reality, support costs are roughly inversely proportional to the number of people at a site. Large sites develop experts who answer internal questions and submit great bug reports.
- Licenses cost money. Another tactic is to imply there's a "cost" of providing you a license. Runtime, development, source, and use licenses may carry big price tags, but, let's be real; that piece of paper costs nothing. It's just something to count.
- We price by what you use to cover our product costs. Bundling is another trick leveraged, often implicitly justified because "more software costs more." However, since shipping costs are zero, it doesn't cost more to ship sixteen pieces of software than it does to ship three. In fact, it costs less. There are no additional support costs for the shelfware the user doesn't even open, and you can ship the same package to every customer, an efficiency that does save money. Bundling can help allocate value, but cost justifications are weak.
- We charge only support and services. The pure-play open-source business model is another example; the idea is to give away the software and charge only for direct costs…in other words, hours. It's the most straightforward of incremental cost justifications.
- This sounds good in theory; you pay only for what you use. In practice, however, it's often terrible. The user is one entity striving only to solve its own needs as inexpensively as possible. There's a lot of "the other guy will pay" mentality, resulting in incomplete solutions and their unfortunate consequences. Many users start blindly down the free primrose path, only to run into these issues and find they need far more hours than expected. This surprise can be unwelcomed, to say the least, because many users start without even checking into upgrade or support pricing models.
- Bottom line: user-paid projects simply don't reward everything required to support an emerging technology. Following the few of those users who are willing or forced to pay is hardly a way to navigate a dynamic industry. While it works in some cases (mostly sophisticated-user-maintained or mature technologies), revenue hours can be a poor driver for strategy and a poor basis for a healthy vendor relationship.
So, if cost isn't the right basis for pricing, how about value?
Software brings real value. For instance, my company's real-time middleware helps you build distributed mission-critical systems. Our software implements a high-quality, reliable, fast, flexible communications infrastructure. It ties a system of diverse applications into a working whole. We solve a challenging problem at the core of our customers' success.
Our software is the result of our combined experience with hundreds and hundreds of problems. We've walked your path before. We have a great team of engineers making sure the product is the best in the world. We professionally track and prioritize requirements of entire markets. We do a very thorough job, through services and sales, of mapping our solution to your problem. We deliver real value, and we do that by reducing your risk, by lowering your development costs, and by guiding your success with the bright light of our experiences.
So software delivers very real value. But vendors can't list value in this form on a price quote.
What do users expect on price quotes? They expect metrics like developer counts, runtimes, support, and product bundles. Unfortunately, the justifications for these "value" charges aren't usually relevant. Some typical value arguments:
Why charge per development seat? The usual argument is that the software brings value to that individual developer. Well, the developer is using the software, but (at least for infrastructure software) the value is really to the project. The software may eliminate an entire expensive and risky team of people from the project, but that one individual working on a GUI display may not even be aware he's using an underlying commercial product. The system value is more than the sum of the value to individuals.
Why charge runtime royalties? It can work; enterprise and desktop software is mostly sold by runtimes. Runtimes make sense for quickly-deployed systems, but often not for complex systems with long development cycles. For these systems, the rationale for charging runtime royalties is often "shared risk;" you only pay if you deploy the code for revenue. But sharing that risk doesn't really bring much value. And there are many reasons you may not deploy. For most software, the real risk reduction value is simple: you may get it wrong if you do it yourself. And that is hard to put on a quote.
Why charge support for everyone? Because charging everyone support gives each engineer the freedom to call. However, as outlined above, that's often not really valuable at all.
And why split the charges into bundles? So you can select what to buy, even though often that selection isn't (or shouldn't) be optional. You need to get the software that does what you need, period. Bundles are great for helping tune the purchase, but in practice there's often little real choice.
So the rationales are often wrong. Nonetheless, value metrics tend to map reasonably well to how much money you have (i.e., projects with more people have more money). More runtimes shipped implies more money received. And projects with larger budgets will "see value" and "pay up" for bundles. So, according to the "dirty little secret" values are better metrics than costs.
In the end, pricing by a value metric is promising. The real problem is that these metrics get used in strange combinations, with misleading justifications, requiring analyses and complex approval chains. That leads to confusion, and confusion leads to surprises.
So what makes sense?
Well…ironically, it almost makes sense to charge you based on how much money you have. More precisely, it makes sense to charge in proportion to how much you are investing in your project. If you have a bigger investment, then you face more risk and more pain. You're thus likely getting more real value, and you should pay for that value. This mapping isn't perfect, but it's not that bad, either. Seeking this goal drives vendors to "follow the money." If they do that, then they develop the best product to fit those segments of the market that are in the most pain and will get the most value and therefore deliver the most return.
The real message is that this model should be open and fair. That requires striving for simplicity without surprise. There's little reason to charge against a confusing array of metrics. Using a single metric that maps to the size of your project (e.g. developers or runtimes) correlates well with value received. It also makes software costs easily modeled. You should be able to choose those few who will interface to support, and only those people should pay. That way, your support interface people can become experts on the technology, thus lowering everyone's costs. Bundles are fine, but the goal should be to fit the solution to the problem, not just to give the appearance of lower cost. And, if the vendor offers an open source or free version, the cost of discovering the flaws or shortcomings of that free version should be open, easily calculated, and known up front.
The burden of making this work does not fall solely on the vendor. Customers must be realistic about software costs. Many of the poor justifications and hidden surprises arise because customers get "sticker shock" when confronted with real costs up front. Customers can ease the process by striving to understand how software companies tick and seeking to be good partners in a healthy relationship. And, that means paying a fair price for value received.
The dirty little secret should not be a secret. It's just good business. If the pricing is open, fair, simple and without surprise, it all makes perfect sense.