A large educational institution went to market for a new Learning Management System (LMS). They hired a consultant who spent several months putting together the procurement process which resulted in a public Request for Proposal (RFP) 150 pages long.
The management team had heard great things about Moodle, and knew that most of their colleagues in the sector had selected Moodle. Surprised that Moodle didn’t respond to their RFP, they selected a proprietary LMS that no one else in the country was using. What isn’t surprising is that they have had cost control, support, and software interoperability issues ever since. Where did they go wrong?
The software market has changed
Government entities and the corporate market are embracing open-source software like never before, primarily for its twin attributes of cost-effectiveness and flexibility. IT departments are more educated on the risks and benefits, and now routinely use open-source applications within large, mission-critical systems.
In parallel, an innovative marketplace has emerged, delivering a range of services such as implementation, maintenance, and customization of open-source software. Forward-thinking governments have developed policy positions to encourage departments to harness the benefits of an 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,” policy statements include:
“Procurement decisions will be made on the basis of the best-value-for-money solution to the business requirement, taking account of total lifetime cost of ownership of the solution, including exit and transition costs…”
“Where there is no significant overall cost difference between open-source and non-open-source products, open source will be selected on the basis of its additional inherent flexibility.”
However, while the uptake of open-source software is undoubtedly growing, there remain significant barriers to adoption due to procurement practices tending to favor, albeit not always intentionally, the typical proprietary software business model. In this article, I explore the reasons why, and recommend how prospective customers can act to ensure they receive all the potential benefits of looking at both proprietary and commercial open-source options.
Comparing the revenues versus services
When you purchase proprietary software, the most common element is a license granting the right to use the software; often this is on a per-user basis, and renewed annually. Because the code is closed, we can view software licensing as a form of rent for the intellectual property encapsulated within the software. In the open-source model, there is usually no corresponding mechanism to receive rent for intellectual property.
Furthermore, for enterprise software there is usually a support agreement which is sometimes mandatory to validate the license. The support agreement will include service levels, and some important business assurances that you will be supported if and when you encounter problems.
Open-source subscription agreements are most often compared to the proprietary support agreement. An open-source subscription offers code support and maintenance, security updates, error correction, and patch updates. Where it differs from a proprietary support agreement is that it includes new features and new version releases. In the proprietary model that is covered by licenses. In either case it’s worth purchasing support as this delivers transparent business value.
In a recent article on this topic, Simon Phipps argues that open-source subscriptions offer much more than simple proprietary support agreements, and that open-source subscriptions should be more expensive than their proprietary equivalents on the basis that they deliver the functionality as well as the extra value of the inherent flexibility and freedoms that open source offers. It’s nice logic, although the reality is that open-source subscriptions tend to be much cheaper than their proprietary equivalents and this may be due to the comparatively wider mix of for-payment, and not-for-payment inputs in many open-source projects. As an example, TotaraLMS is a distribution of Moodle, and therefore the sunk costs of developing Moodle are not reflected in a Totara subscription, only the specific costs associated with developing and supporting the Totara extensions.
The challenges with procurement
The models seem straightforward enough so why 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 the vendor’s expense. Proprietary software vendors will put together bid teams and spend the requisite weeks of effort to respond because, over time, when they win a bid, they will more than recoup the cost of the tender response through their licensing fees. This is one of the contributing factors as to why license fees have an opaque relationship with the true value of the intellectual property being “rented” through licenses.
There is no corresponding inbuilt mechanism for the open-source vendor to recoup the cost of sale when responding to a proprietary-styled RFP. In most instances, the investment in pre-sales can’t be readily recouped so it is simply not logical to respond.
There are several other typical pre-sales activities that cause similar problems for the open-source vendor. Free trials or proof-of-concept installations, often with extensive pre-sales consulting thrown in, naturally incur a cost. The proprietary vendor takes the approach of recouping through license fees. In a sense, the large pre-sales investment that still ends in unsuccessful sales is simply borne by customers paying high license fees typical of enterprise proprietary software. In addition, the vendor can uninstall or disable the proprietary software if a trial doesn’t translate into a sale. Not so with open-source software – the would-be customer already has the code and has chosen not to purchase the support contract. The free trial carrot doesn’t have the same proprietary stick accompanying it.
A key benefit of open source is the absence of vendor lock-in. This is as it should be from the client’s perspective, but from the vendor’s standpoint there is risk when investing in pre-sales that another entity may reap the reward of that effort. Furthermore, a customer may decide to take the basic subscription but none of the value-added services. This presents another disincentive for extensive and unrewarded efforts in pre-sales. With open source, a vendor makes money from selling services around the code, not for selling the code itself.
Who’s missing out and who stands the most to gain or lose if this procurement model was reframed to achieve a balanced evaluation of all options? Under the heavy proprietary-styled RFP process, or other pre-sales activities like free trials or proof-of-concept implementations, both the customer and the open-source vendor are losing out. By excluding the open-source options, the customer is likely to pay much more for their solution and more importantly, be locked in for years to come, losing the software freedoms available to them from the open-source model.
If the procurement process was re-framed to establish a more level playing field, then the client stands to benefit from more pressure being brought to bear on the largesse of proprietary licensing fees.
Recommendations for re-framing the procurement process
The following recommendations are not interrelated nor are they mutually exclusive.
- First and foremost, balance your investment in the RFP process with real research into the options in the market. This may include using an initial Request for Information (RFI) that allows for responses to be in the vendor’s formats, e.g. information packs, brochures, or product sheets. You then have the option to prioritize the vendors and select respondents for a closed RFP.
- Split the procurement into two parallel processes. One RFP designed for proprietary solutions and one for open-source solutions. Write the second RFP overtly 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-source license is being used, availability of commercial support, reputation of suppliers, and their product development model.
- Include a two-stage procurement component with a paid-for discovery stage 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 questions you 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, undertake the research internally or engage a suitably qualified third-party consultant who is abreast of the potential open source solutions and their benefits.
In other words, do not expect the open-source vendor to operate in the same way as a proprietary software vendor. The software development models are different, and so are the business models.
In conclusion, procurement models need to reflect the changes now occurring in the software marketplace. If the prospective purchaser doesn’t adapt their procurement decision-making processes, then it is only logical they will receive a sub-set of the options.
By leveling the playing field with some understanding and appreciation of the different business models on offer, buyers of enterprise software stand to gain enormously from more choice, lower cost of ownership, freedom from vendor lock-in, control over their system’s direction, and flexibility to extend or customize their solution. In summary, this is known as software freedom, and the demand-side has as important a part to play as the supply-side.
References
Phipps, Simon. Open Source Procurement: Subscriptions. Opensource.com, March 2011 http://opensource.com/life/11/3/open-source-procurement-subscriptions
Cabinet Office. “Open Source, Open Standards and Re-Use: Government Action Plan”, January 27, 2010.