When you procure proprietary software, you buy a right-to-use license and then a support agreement. But when you buy open source, you already have the right-to-use from the OSI-approved free license, so you should compare the subscription cost with just the cost of a proprietary support agreement. Right?
Wrong! The open source subscription includes all the same elements as the combination of both purchases. In most cases, if you are receiving equivalent value, you should expect to pay similar prices.
This is not a TCO question; it's a straightforward matter of ensuring you compare like with like. In general, I also believe the TCO of a genuine open source solution will be lower than that of a proprietary solution. As I explain below, the cost savings of open source arises not from the price of the license, but from the liberty it permits - the flexibility to use the software anyhow you want, to hire experts who are free to study it, to buy in a market that's free to work directly with the source and to share the software with anyone anywhere to make your work more effective.
The word "free" in the expression "free software" seduces us into believing that somehow open source subscriptions should be much cheaper than their proprietary equivalents. But the truth is that, if anything, the extra value of the liberties open source delivers means it probably ought to cost more! The fact it doesn't is more a reflection of the ability of your proprietary suppliers to force you to pay over-the odds and thus fund their immense wealth.
That liberty to decide whether to hire staff, subscribe or simply use at your own risk - in other words, to control your own budget and destiny rather than hand control of both to a supplier - is what makes open source a massive "win" for most companies.
Buying proprietary software
Let's look at how procuring subscriptions for open source software differs from procuring proprietary right-to-use licenses and support agreements. When you buy proprietary, you will most likely buy two things:
- A license granting the right to use the software. There's no real reason why that needs paying for, but for most suppliers it's a handy control point where they can force you to contribute towards the cost of creating the software and towards the cost of creating the new features in the next version.
It comes as a surprise to some to discover this is actually a recurring cost. Most likely you will also need to update, renew or upgrade this license when the next version comes out. It's also possible the license will be predicated on having a valid support agreement. - A support agreement. This is worth paying-for as it delivers real business value. Without it, you'd be on your own when you ran into problems. With it, you have someone to report problems to, and hopefully you'll receive the assistance you need to work round the problem and ultimately to correct it. Your support agreement will be codified into some sort of service level agreement, telling you how often you can call, when you'll get an answer and how hard the supplier will work on helping you.
As well as paying for the staffing and infrastructure to provide all this, the money you pay goes towards "sustaining" the product - that is to say, keeping it working as the environment around it changes. Sustaining includes testing the software on new versions of the operating system or application server, for example.
You'll need to keep this agreement up-to-date, so you'll need to pay for each year that's covered by it. You will also need to have a right-to-use the software, so you will need to keep that up to date as a precondition.
Both of these things will be priced to also cover the cost of selling them to you - a substantial cost since most commercial tendering processes involve extensive work by experts in order to create a response. Both will also include a mark-up so that the transaction is profitable for your supplier. You'll also note that both items will be likely to need regular renewal, and that both are probably linked to each other, forming in a sense a single transaction spread over time.
Buying open source
When you buy a subscription to open source software, you are paying for all the same things to one degree or another. While the fact you are free to use the software for any purpose means there is no compulsion to pay--you always have the right to use the software--all of the same things that are in both items above still need to be paid for. A subscription is just a more flexible way of distributing the costs of creating and sustaining the software and rolls both of those costs in with the cost of the service level agreement you need.
It's in your interests for this to be the case. You don't want to be left without support, sustaining or ongoing development. It's simply good sense to protect your investment in the software by contributing to its ongoing development through your subscription supplier in this way. But you have software freedom too, not just your supplier.
As well as being cheaper to own because there's no need for license management, there are two reasons the price is likely to be a little less for an open source subscription than for a proprietary right-to-use/support agreement combination taken together over a similar period:
- The first is that cost of sale could well be lower, as you are free to adopt the software first and subscribe later. If your procurement process makes no allowance for an adoption-led approach, you will not be able to realise this cost saving as your supplier will have to work just as hard to sell to you and will thus have to reflect that in the price.
- The second is that the cost of creating the software might be lower. In an open source community, every participant pays their own way and reaps their own reward, so the sunk cost of creating the software doesn't necessarily have to be reflected in the price. However, your supplier still needs to employ a reasonable number of community members to contribute to future versions, so this cost saving is unlikely to be huge.
Chalk and cheese
Comparing the cost of your subscription with the cost of the competing proprietary solution is not easy, but if you do you are likely to find that over the lifecycle of the software the costs are broadly comparable - if you choose to buy all the things that are covered. But that's a big "if"--the chances are you won't do that.
The great benefit of open source--and the liberty it brings--is that you get to decide. You can choose to hire or assign your own staff to cover some of the support. You might choose to have your own developers work in the community for part of the lifecycle. You can turn the support agreement on and off throughout that lifecycle without losing the right to use the software. And the chances are that the market for delivering a subscription on any given open source project will be competitive, keeping costs down as a consequence. No proprietary lock-in means your suppliers have to stay lean and effective.
The lesson to draw from all this is that you can't compare the open source subscription with just the support agreement from a proprietary product, and there is a flexibility in open source subscriptions that allows you to control costs in a way that's almost never available from proprietary vendors, who are much more likely to put their prices up once you're locked in, and worse to leverage that lock-in to secure more and more of your IT spending.
So make sure your procurement policy reflects these realities and doesn't just assume open source can be handled the same way as proprietary. It can't, and if you try you'll not reap the rewards of the liberty open source brings.
This article was originally posted at ComputerWorld UK. You can follow Simon as @webmink on Twitter and Identi.Ca.
Comments are closed.