Open source’s unlikely enemy: Your procurement rules

In a public discussion last week, I heard one of the speakers — a spokesman for a large proprietary software company — alleging that “the lack of any indemnity in open source makes it more risky.” Naive as I am, I had assumed that moldy anti-open-source argument had gone out of favor long ago. Apparently not.

But it did remind me that the indemnity issue is one of those red herrings that your procurement policies may be perpetuating. If you want to get more open source software into your enterprise and benefit from the greater flexibility of software deployment and control over your own destiny, you have to update your procurement rules to allow it.

[ Also on InfoWorld: Simon Phipps expounds on the inherent evil of software patents. | Track the latest trends in open source with InfoWorld’s Technology: Open Source newsletter. ]

Your procurement rules have gradually built up as you’ve played the procurement game with your suppliers. At its rawest, the vendors’ game is a chase to obtain as large a share of your IT budget as possible, preferably locked-in so that it becomes recurring revenue, while exposing themselves to the least cost and risk possible. Your suppliers’ tools of choice are proprietary software, proprietary data formats, and as much complexity as can be slathered into the solution.

But all those things are bad for you. In the absence of choice, your procurement rules will have tried to triage each of those wounds:

• To deal with proprietary software, you may well require release commitments, service commitments, escrow arrangements, and indemnity promises.
• To deal with proprietary data formats, you probably have some requirement for standards, which by now will have been gamed by your suppliers.
• As for the complexity — well, each time the solution is proprietary, the only way to deply it likely requires consulting agreements with vendor-certified staff.

Open source brings new opportunities, but your biggest obstacle to accessing those opportunities may ironically be your own defenses against proprietary suppliers: those procurement rules that have evolved to be complex and inflexible. Although these rules may provide both protection and value for procurement of products and services the enterprise has seen before, they typically discriminate against new product and vendor business models. These new solutions can easily become “friendly fire” casualties of unintended and unforeseen consequences from legacy procurement rules.

There are several examples of this effect. For example, you may regulate maximum support costs as a percentage of the licensing fees, without having considered what would happen if those licensing fees were zero. You may require contractors to give you ownership of the copyright of work they perform for you, without exceptions for work performed on an open source code base. You may have no way to size and accept subscription fees, a common approach by open source suppliers to fairly recover their costs of delivering value to you. There are many more of these cases affecting pricing, warranties, standards, and terms of service.

Just to work through one example, consider the case of an indemnity requirement, that red-herring issue I heard last week. You need contractual indemnity when you procure proprietary software because you have no other way to protect yourself against careless or malicious infringement of the rights you can reasonably expect to be protected. You thus require the company that owns the software — the one entity that has the data to know the risk — to put its money and reputation behind the assertion it has not allowed anything harmful to enter the software before it was delivered.

By contrast, a company selling a subscription for an open source project isn’t actually the owner of the software. The subscription may superficially resemble a right-to-use or end-user license agreement, containing as it does both a service-level agreement and an agreement to continue developing the software. However, there’s no actual software supply involved. The software is instead entering your enterprise under the terms of an open source license, direct from the many community participants.

As such, the company selling a subscription guaranteeing ongoing development and support of that software won’t offer an indemnity for two reasons. First, they aren’t the supplier of the software — the community is. Second, there’s another way to mitigate the risk from the software: see if the community is happy using it. As long as there’s a sufficiently diverse community, this is likely to be sufficient risk mitigation. This mystifies procurement staff enforcing legacy procurement rules. The transaction looks to them like a software purchase, yet there’s no indemnity.

Of course, such a company might offer indemnity, but if it does (and is doing so honestly!), it will also need to purchase its own insurance to cover the risk it is taking. It will pass that cost on to you, plus some markup. So, it is cheaper for you to buy the indemnity insurance yourself if you truly need it.

That’s a short and simplistic explanation, but it illustrates the issue. Open source isn’t just another kind of software that’s cheaper. It’s software developed in a new way, by developers exploiting licenses and community rules guaranteeing them the rights to use, study, modify, and distribute the resulting software any way they want. For your enterprise to truly get the most from those open source freedoms, you need to make sure your procurement rules don’t force you to use only proprietary-software vendors.

Maybe it’s time for a review?

This article, “Open source’s unlikely enemy: Your procurement rules,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.