TECH DYNAMICS: Last Friday, June 25th, the US House and Senate reached agreement on a financial reform bill, which is likely to pass and be signed into law.* At first glance, this legislation has nothing to do with the IT industry directly. But buried in this bill is a provision regarding debit card fees, which could serve as a model for how end users of software could bring about a change in something that is very important to the economics of the software industry — software maintenance fees.

Now, software maintenance fees have been one of the givens in the software industry in perpetual license deals. Typically set at 18% to 22% of initial license fees, they are fixed in stone. An enterprise software buyer can try to negotiate a discount on a license fee; a really smart one can negotiate a deal where the maintenance fee rate is applied against the discounted license fee, not against the list license fee. But software vendors rarely discount maintenance fees. 

Why? Established software vendors depend heavily on maintenance fees for the bulk of their revenue. Almost half (49%) of SAP’s revenues and Oracle’s applications revenues in 2009 came from maintenance fees. Oracle’s middleware business earned 55% of its calendar 2009 revenues from maintenance fees.

And yet maintenance fees are one of the biggest sources of complaint from enterprise software buyers. Every so often this dissatisfaction breaks into the open. SAP faced massive client unrest when it raised maintenance fees for most customers during 2009. SAP tapped the biggest vein of resentment about maintenance fees: fees on old software. Old software is the crux of the problem with maintenance fees: It tends to be stable and therefore requires little support.

Let’s look back at the initial logic behind maintenance fees. Maintenance fees fund three sources of value to the enterprise software buyer:  1) access to product support (help desk, bug fixes, etc.); 2) changes made to software to support legal and regulatory compliance; and 3) access to product improvements in feature and function. 

Now, consider a new software product that is released in its 1.0 version and that is sold with a perpetual license to use that software and annual maintenance fees. The history of software products shows that the new product will on average go through three releases in the first five years (at two years between releases), with major enhancements in feature and function in that time frame. In fact, those enhancements are likely to be so significant and the 3.0 version will be such a dramatically improved product compared with the 1.0 version that it is, in effect, a new product. In the absence of a perpetual license, a buyer would want to buy that 3.0 version at about the same price that it paid for the 1.0 version. By setting the maintenance fee at 20%, the software vendor effectively allows the software buyer to do that over time — plus get access to product support during that time frame and access to all the new enhancements in the versions 1.x and 2.x along the way. All in all, that’s a bargain for the software buyer, and it makes 20% maintenance fees well worth paying.

But what happens after the first five years? Inevitably, the pace of innovation slows, the features and functions that get added are less important. So, the 5.0 or the 6.0 version is maybe only a 30% or 40% improvement over the 3.0 version. Now, the 20% annual maintenance fee is looking like less of a bargain. At best, the value the buyer receives in product support and new enhancements over those five years is equal to the sum of five 20% annual maintenance fees; in many cases, it is less. And after 10 years, the product is now very mature, the 7.0 or the 8.0 version is only a 5% or 10% improvement over the 5.0 or the 6.0 version, and the need for help desk support and bug fixes is close to zero. At this point, that 20% annual maintenance fee is looking way out of line with the value the enterprise software buyer is actually getting.

In an economically rational world, therefore, software maintenance fees ought to decline as the product matures and ages. Indeed, for a typical licensed software application, software maintenance fees should be 20% for the first five years of the product’s life, 15% for the second five years, 10% for the third five years, and 5% thereafter. Of course, there will be many exceptions, e.g., there are sufficient enhancements to the product after the first five years to justify higher maintenance fees beyond that point. But there will also be cases in which all the enhancements occur in the first two or three years, so a faster ramp down of maintenance fees would be justified. 

Software vendors argue that this analysis may ignore major platform shifts, such as the movement to Web-based architectures in the late 1990s and early 2000s. Those platform shifts can create new value for clients, in terms of reduced cost of operation, lower cost of integration, and better ability to meet new business requirements. Even so, it’s hard to argue that the new value in product capabilities created every five years in a mature product is worth the price of a brand new product — which is what a buyer is paying for after five years of 20% maintenance fees. And many vendors fumble platform shifts anyway!

What sustains the current 18% to 20% maintenance fee structure is instead pure monopoly power on the part of the software vendors. Software vendors know that the cost to a buyer of shifting from one software product to another is effectively prohibitive. And because all major software vendors use the same 18% to 22% maintenance fee structure, the enterprise buyer knows that it will not get a big cost savings by switching so it’s trapped.

The result is a maintenance fee structure that stands like the Rock of Gibraltar — an unchangeable reality in the market, a source of great profits for software vendors, and a source of resentment among customers.

Now, let’s turn back to the financial reform bill that is about to become law in the US. That reform bill contains a provision that attacks another fee structure that has seemed to have the same Rock-of-Gibraltar stability as software maintenance fees: the discount fees that Visa and MasterCard banks charged merchants for acceptance of debit cards. Like software maintenance fees for CIOs, the discount rates of 1% to 2% of the value of every Visa and MasterCard debit card transaction that merchants paid became a source of dissatisfaction to merchants. And, as with software maintenance fees on mature software products, that dissatisfaction had its roots in an imbalance between the cost of these fees and the value that merchants received.

The first debit cards were bank-issued cards with online connections to a customer’s checking account. So, when a customer made a purchase using the debit card, funds were transferred from the customer’s bank account to the merchant’s bank account on the same day. Because there was very little risk and almost no funding cost, these online debit cards had very low discount rates — often, just 0.1% or 0.2% of the value of the transaction. However, Visa and MasterCard then started issuing offline credit cards, which did not have the online connection to the customer bank account. Settlement instead occurred one or two days after the transaction, when funds to cover the cost of the purchase were transferred from the customer’s bank account to the merchant account. Because these offline debit cards had higher risk of nonpayment and higher funding costs, Visa and MasterCard initially charged slightly higher discount rates to merchants — around 0.5%. But then Visa and MasterCard got greedy — they used their monopoly power to raise the discount rates on offline debit cards to 1%, then to 1.5% (close to the discount rate for credit cards), telling merchants that if they wanted to accept Visa and MasterCard credit cards, they had to accept Visa and MasterCard debit cards at these discount rates.

That imbalance of value between what merchants were getting for accepting Visa and MasterCard credit cards and Visa and MasterCard debit cards with increasingly similar costs sparked a merchant revolt. Walmart and other big merchants started filing legal challenges against Visa and MasterCard and then took their complaints to Congress. Joined by small merchants, the merchant community persuaded Congress to include in the Senate version of the financial reform bill a provision that instructs the Federal Reserve to issue regulations to reduce the discount rates charged to merchants on debit cards. With the House of Representatives now accepting the Senate provision (with minor modifications) in the final bill, what looked like an unbreakable fee structure for debit cards will be broken.**

Software vendors should take note. I think it’s only a matter of time before CIOs start sitting down with the CEOs to talk about this issue, eventually getting their CEOs to lobby the US Chamber of Commerce, the National Association of Manufacturers, and other business organizations to push Congress for similar remedies. That matter of time may not be in 2010 or 2011. But sooner or later, I think the software industry will be forced by external action to change its maintenance fee structure. Where there is precedence, as there is here, there will be repetition of history.

So, what should software vendor strategists do? Well, since there is no immediate sign of regulatory or legislative challenges to the maintenance fee structure, the short answer is — nothing. Why prepare for something that hasn’t happened? If and when signs do emerge, the obvious step would be to start mounting a counter-offensive — preparing legal teams to defend the software maintenance fee structures, building the arguments to present to Congress about why the software maintenance fee structure is so critical to software innovation. After all, so many software vendors are so dependent on maintenance fee revenues that it is almost unthinkable that they would abandon the current structure without a fight.

But let me suggest an alternative. The maintenance fee structure of today originated at a time in history when software was still new and still rapidly evolving. It’s doubtful that many of the designers of that maintenance fee structure foresaw the day that SAP’s R/3 software product (as an example) would be 20 years old, as it will be in 2012. So, they never really thought through the implications of a 20% maintenance fee applying to products that would be 20 years old. Maybe it’s time to revise that model to take account of the learnings about the maturation process of software products that we have gained in the past 20 years. Maybe it’s time to move to a sliding scale of maintenance fees, based on the age and maturity of the product. Yes, that would hurt revenues in the near term. But, it would improve the price-value equation for licensed software and restore its competitiveness with subscription-based software-as-a-service (SaaS) products. That step would certainly increase the likelihood that CIOs would never make this a CEO-level issue that leads to lobbying of Congress for relief. And it probably would make CIOs more willing to invest in licensed software, because they would know that they would in fact be getting value proportional to the maintenance fees they pay.

 

*Source: Edward Wyatt and David M. Herszenhorn, “In Deal, New Authority Over Wall Street,” The New York Times, June 25, 2010 (http://www.nytimes.com/2010/06/26/us/politics/26regulate.html?dbk)

**Source: Binyamin Appelbaum, “Tentative Deal Reached to Limit Debit Card Fees,” The New York Times, June 21, 2010 (http://www.nytimes.com/2010/06/22/business/22regulate.html?scp=1&sq=Debit%20card%20fees&st=Search)