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.
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.