Leveling the Software-procurement Playing Field

A large educational institution went tomarket for a new Learning Management System (LMS). They hired a consultant whospent several months putting together the procurement process which resulted ina public Request for Proposal (RFP) 150 pages long.

The management team had heard great thingsabout Moodle, and knew that most of their colleagues in the sector had selectedMoodle. Surprised that Moodle didn’t respond to their RFP, they selected aproprietary LMS that no one else in the country was using. What isn’t surprisingis that they have had cost control, support, and software interoperabilityissues ever since. Where did they go wrong?   

The software market has changed

Government entities and the corporatemarket are embracing open-source software like never before, primarily for itstwin attributes of cost-effectiveness and flexibility. IT departments are moreeducated on the risks and benefits, and now routinely use open-sourceapplications within large, mission-critical systems.

In parallel, an innovative marketplace hasemerged, delivering a range of services such as implementation, maintenance, andcustomization of open-source software. Forward-thinking governments havedeveloped policy positions to encourage departments to harness the benefits ofan increasing pool of mature enterprise-level open-source software.

For example, in the UK’s report “Open Source, Open Standards and Re-Use: Government Action Plan,” policystatements include:

“Procurementdecisions will be made on the basis of the best-value-for-money solution to thebusiness requirement, taking account of total lifetime cost of ownership of thesolution, including exit and transition costs…”

“Where there is nosignificant overall cost difference between open-source and non-open-sourceproducts, open source will be selected on the basis of its additional inherentflexibility.”

However, while the uptake of open-sourcesoftware is undoubtedly growing, there remain significant barriers to adoptiondue to procurement practices tending to favor, albeit not always intentionally,the typical proprietary software business model. In this article, I explore thereasons why, and recommend how prospective customers can act to ensure theyreceive all the potential benefits of looking at both proprietary andcommercial open-source options.

Comparing the revenues versus services

When you purchase proprietary software, themost common element is a license granting the right to use the software; oftenthis is on a per-user basis, and renewed annually. Because the code is closed, wecan view software licensing as a form of rent for the intellectual propertyencapsulated within the software. In the open-source model, there is usually nocorresponding mechanism to receive rent for intellectual property.

Furthermore, for enterprise software thereis usually a support agreement which is sometimes mandatory to validate thelicense. The support agreement will include service levels, and some importantbusiness assurances that you will be supported if and when you encounterproblems.

Open-source subscription agreements aremost often compared to the proprietary support agreement. An open-sourcesubscription offers code support and maintenance, security updates, errorcorrection, and patch updates. Where it differs from a proprietary supportagreement is that it includes new features and new version releases. In theproprietary model that is covered by licenses. In either case it’s worthpurchasing support as this delivers transparent business value.

In a recent articleon this topic, Simon Phipps argues that open-source subscriptions offer muchmore than simple proprietary support agreements, and that open-sourcesubscriptions should be more expensive than their proprietary equivalents onthe basis that they deliver the functionality as well as the extra value of theinherent flexibility and freedoms that open source offers. It’s nice logic,although the reality is that open-source subscriptions tend to be much cheaperthan their proprietary equivalents and this may be due to the comparativelywider mix of for-payment, and not-for-payment inputs in many open-sourceprojects. As an example, TotaraLMS is a distribution of Moodle, and thereforethe sunk costs of developing Moodle are not reflected in a Totara subscription,only the specific costs associated with developing and supporting the Totaraextensions.

The challenges with procurement

The models seem straightforward enough sowhy are there any problems?

First, Requests for Proposals (RFPs) are,more often than not, innately weighted towards a proprietary software outcome.These are often huge, complex documents with responses explicitly at thevendor’s expense. Proprietary software vendors will put together bid teams andspend the requisite weeks of effort to respond because, over time, when theywin a bid, they will more than recoup the cost of the tender response throughtheir licensing fees. This is one of the contributing factors as to why licensefees have an opaque relationship with the true value of the intellectualproperty being “rented” through licenses.

There is no corresponding inbuilt mechanismfor the open-source vendor to recoup the cost of sale when responding to aproprietary-styled RFP. In most instances, the investment in pre-sales can’t bereadily recouped so it is simply not logical to respond.

There are several other typical pre-salesactivities that cause similar problems for the open-source vendor. Free trialsor proof-of-concept installations, often with extensive pre-sales consultingthrown in, naturally incur a cost. The proprietary vendor takes the approach ofrecouping through license fees. In a sense, the large pre-sales investment thatstill ends in unsuccessful sales is simply borne by customers paying highlicense fees typical of enterprise proprietary software. In addition, thevendor can uninstall or disable the proprietary software if a trial doesn’ttranslate into a sale. Not so with open-source software – the would-be customeralready has the code and has chosen not to purchase the support contract. Thefree trial carrot doesn’t have the same proprietary stick accompanying it.

A key benefit of open source is the absenceof vendor lock-in. This is as it should be from the client’s perspective, butfrom the vendor’s standpoint there is risk when investing in pre-sales thatanother entity may reap the reward of that effort. Furthermore, a customer maydecide to take the basic subscription but none of the value-added services.This presents another disincentive for extensive and unrewarded efforts inpre-sales. With open source, a vendor makes money from selling services aroundthe code, not for selling the code itself.

Who’s missing out and who stands the mostto gain or lose if this procurement model was reframed to achieve a balancedevaluation of all options? Under the heavy proprietary-styled RFP process, orother pre-sales activities like free trials or proof-of-conceptimplementations, both the customer and the open-source vendor are losing out. Byexcluding the open-source options, the customer is likely to pay much more fortheir solution and more importantly, be locked in for years to come, losing thesoftware freedoms available to them from the open-source model.

If the procurement process was re-framed toestablish a more level playing field, then the client stands to benefit frommore pressure being brought to bear on the largesse of proprietary licensingfees.

Recommendations for re-framing the procurementprocess

The following recommendations are notinterrelated nor are they mutually exclusive.

1. First and foremost, balance your investment in the RFP process withreal research into the options in the market. This may include using an initialRequest for Information (RFI) that allows for responses to be in the vendor’sformats, e.g. information packs, brochures, or product sheets. You then havethe option to prioritize the vendors and select respondents for a closed RFP.
2. Split the procurement into two parallel processes. One RFP designedfor proprietary solutions and one for open-source solutions. Write the second RFPovertly for an open-source solution. On top of the attributes of the product,criteria for selection will differ in some areas such as which open-sourcelicense is being used, availability of commercial support, reputation ofsuppliers, and their product development model.
3. Include a two-stage procurement component with a paid-for discoverystage of 1-2 weeks on your short-listed open-source candidates. In other words,engage the potential vendor commercially to help answer all of the same questionsyou may be expecting from the proprietary vendors as part of their pre-sales.If you think it’s anathema to consider paying for any pre-sales activity, undertakethe research internally or engage a suitably qualified third-party consultantwho is abreast of the potential open source solutions and their benefits.

In other words, donot expect the open-source vendor to operate in the same way as a proprietarysoftware vendor. The software development models are different, and so are thebusiness models.

In conclusion, procurement models need toreflect the changes now occurring in the software marketplace. If theprospective purchaser doesn’t adapt their procurement decision-makingprocesses, then it is only logical they will receive a sub-set of the options.

By leveling the playing field with someunderstanding and appreciation of the different business models on offer,buyers of enterprise software stand to gain enormously from more choice, lowercost of ownership, freedom from vendor lock-in, control over their system’sdirection, and flexibility to extend or customize their solution. In summary,this is known as software freedom, and the demand-side has as important a partto play as the supply-side.

References

Phipps, Simon. Open Source Procurement: Subscriptions. Opensource.com, March 2011 https://opensource.com/life/11/3/open-source-procurement-subscriptions

Cabinet Office. “Open Source, Open Standards and Re-Use: Government Action Plan”, January 27,2010.