In this series Tim gives us a quick guide to negotiating more favourable licensing agreements.
PART THREE – The Software Maintenance Game
As we all know, there’s a lot of buzz these days about inflated maintenance charges. Frankly, I think users of commercial software are moving beyond frustration and on to anger, and reading articles about the 85% profit margin that Oracle enjoys on its maintenance fees, for example, only fuels the fire.
In addition to introducing flexibility on maintenance terms (Part 2), software buyers should keep the following points in mind when negotiating maintenance terms and options.
- There’s the notion that a chunk of software may be entirely new to a buying organization, but the software itself may be old. Buyers need to gauge where a software product is in its lifecycle, and react to maintenance options accordingly. Naturally, if the software has a grey beard, there probably won’t be another major release. So, why pay for something that you’re never going to receive?
- Second, most of my clients pay maintenance on most of their applications, but they rarely install updates (everything works fine for them and they don’t want to risk an adverse event that might result from installing an update). This makes no sense to me (the paying for maintenance part). If your organization never installs updates, then why ever sign on for maintenance at time of acquisition? The same is true if you updated for some time period, but haven’t in recent years. Drop the maintenance! You may not be eligible for support at some point after going naked on maintenance, but that is not an issue for many organizations, especially for mature deployments.
- Third, software buyers need to stop being angry about maintenance costs and doing nothing about it, in my opinion. Some new concepts are gaining traction and may eventually change the nature of software maintenance permanently. But software buyers must start demanding alternative maintenance options in order for these new concepts to take hold.
One new concept is “reverse maintenance”, and the notion is this. Instead of paying up front for something that I may never receive (or not want if I do receive it), why can’t I pay later for the something; that is, when I receive it and if I want it? Seems fairer to me, and it would actually incent software vendors to create and improve their products. Under the current model, software vendors take in the same amount of maintenance fees regardless of whether they deliver anything (of value) in return.
The other new concept is “pay for performance”, and one version of it works like this. You pay your maintenance fees up front, but you are entitled to reimbursement depending on what your vendor actually produced during the prior maintenance revenue period. One obvious shortcoming of this approach is that it incents your software vendor to produce something during a maintenance revenue period, but not necessarily something that is of value to users. Should the reimbursement metric be based on volume of stuff produced, value of stuff produced, or both? If value figures into the equation, how are we to measure value?
In all events, software buyers want and deserve better (more realistic) maintenance options. If software vendors don’t respond with a better maintenance model, more and more software buyers will opt for no maintenance—whether at time of acquisition, or perhaps sooner in an application’s lifecycle.
Just to clarify, when a software buyer chooses not to buy maintenance at time of acquisition, or should a buyer attempt a reverse maintenance or similar concept, the buyer can expect to pay a higher license fee. This is to be expected, and it will vary across acquisitions, but the hike in the license fee will usually be much less than the sum of (normal) annual maintenance fees paid out over the life of the application.
About Martin Thompson
Martin is also author of the book "Practical ITAM - The essential guide for IT Asset Managers", a book that describes how to get started and make a difference in the field of IT Asset Management.
On a voluntary basis Martin a contributor to ISO WG21 which develops the ITAM International Standard ISO/IEC 19770.
Learn more about him here and connect with him on Twitter or LinkedIn.