How to Procure Open Source

As part of my work as a Board member of the Apereo Foundation, we’ve been working on new content to more clearly make the case for adopting open source, particularly in education. Alongside that we’ve been working on developing open source health measures that will give transparency about how a project is operating, and help support institutional decisions about adoption. *

This is a topic close to my heart. So close in fact I gave a talk back in 2010 at what was then the Jasig annual conferenceĀ (one of the communities that merged to form Apereo a few years later) about how to “procure” open source solutions.I was hearing over and again complaints that it was hard to “procure” open source via conventional competitive procurement / RFP processes and I thought that the approach being taken was fundamentally wrong. I used the work I was involved in at the time – developing a new identity management infrastructure for my institution – as a case study exemplar of how to run an alternative sourcing process that would allow consideration of open source.

Whilst that example is old now, the approach I took is still sound, and since I still keep hearing the same complaints about the practical difficulties of procurement processes, and how to actually get open source options onto campus, I’m going to revisit it here. I’ve done a lot more procurement in the intervening years, including contributing to sector level frameworks, and sourcing most of the major edtech components for my institution. I hope that means I know a thing or two.

The first thing to address straight off the bat is the question of how to get open source via an RFP / competitive procurement process. The simple answer is that you don’t.

That’s comparing apples with pears and most open source projects are not resourced at a level that allows them to easily bid into an RFP process. In pursuit of some perception of “fairness” these processes are almost always biased towards commercial enterprises with marketing teams. Also, in the EU and I imagine elsewhere, where a piece of software is free to use for the whole of it’s life there’s simply no requirement to use a competitive procurement process.

However, it is still important to look at whole life costs in particular to be certain that (a) open source is going be the best value for money (b) there isn’t a need for commercial support and maintenance contracts that does need to be procured through a commercial tender process. It’s also important to look at risks and sustainability. In the same way as you would inspect the financial standing of a commercial supplier, you need to do an assessment of the long term viability and sustainability of your preferred open source option. Finally, you do still need to do due diligence on functional fit.

So, how to get started? Too often I see procurement processes being used as the first step into testing a market and this is where I think another fundamental problem lies. Don’t use an RFP process for market insight – more often than not you are going to get badly stung by doing that. Obviously you don’t want to prejudge the market too heavily, but every decision to invest in a new system should start with some market analysis to understand broadly what’s out there, who’s already playing in this space, what the major points of differentiation are, and how aligned to your strategic needs and goals the market seems to be. Understanding this is vital to controlling your procurement and getting the right result, and it’s in this phase that you should be considering open source options as well as commercial (actually, in my perfect world, we would be drawing up fully costed business cases in advance of committing to invest in something new, and that’s where we would initially make the case for open source).

There are many reasons for why open source might be a better fit than a commercial offering, not least of which are innovation, influencing direction of travel, and avoiding vendor lock-in. If you think that open source might well be the best fit for your institution, then it’s still important to do that full assessment to check this thinking. Being open on it’s own merits isn’t enough and I worry sometimes that evangelising for open source without a transparent decision making process does more harm than good. Although open source requires a different sort of investment (people time, rather than cold hard cash) we are still investing in institutional systems, and probably using public money to do so, and so we care about all the same things including functional fit, sustainability, roadmap, ability to influence product development, and total cost of ownership.

Your market analysis should already have generated a set of requirements and high level weightings that you would have worked up as the basis for a competitive procurement process. You should also have a rough idea of book price for the various commercial options out there. This is what you should be using to assess functional fit of your chosen open source option too (indeed you may be assessing more than one option – for example there are multiple open source options within the LMS space).

Beyond that you will need to look at using an open source maturity model to assess total cost of ownership and long term sustainability. There are a number of them out there, most of them quite long in the tooth, but still pretty sound. There’s a short but useful paper from 2017 that does a quick comparison across them and the conclusion has some useful observations which would help combine the various features of each to get something fit for purpose:

“It has been observed that all existing OSS maturity models selection guidelines follow similar criteria. All maturity models does not focus on interoperability except EOSS. For any component to be considered as enterprise ready interoperability must be needed.

Open BRR, N-OSMM and C-OSMM does not consider IT management and administration as a criteria whereas QSOS consider IT management under training, consulting and support criteria. C-OSS does not count on weighted score method.

In order to take advantage of OSS properly, it is recommended to propose a new framework / model that will eliminate the weakness of all models.” (Comparison of open source maturity models)

There are also a number of old, but still totally relevant advice articles from the OSSWatch project:

(This is the point at which work like we are planning within Apereo on open source health measures becomes important. We want it to be as simple as possible to assess the sustainability of our project so that the route to adoption is as smooth as possible).

So by this stage you should have a set of documents that assess functional fit, demonstrate that choosing open source is good value for money (whether that means cheaper, or better fit for comparable money), and assess the long term sustainability and risks for going open. Yes, you’ve had to do a chunk of this work yourself, rather than relying on a commercial company to fill out the paperwork for you; however, I’ve never yet met a procurement that didn’t require substantial clarifications, so I’m to be convinced this is a whole lot more effort in the long run.

What I can’t be prescriptive about is what institutional governance processes you might have to use to get approval once you’ve done this work. However I do believe that this is a credible way of approaching the adoption of open source that can be aligned well with institutional needs and strategies and allay concerns about sustainability and support in ways that are well evidenced.

I’d be interested in other people’s experiences in this area. Are there other routes which have worked for you? Would you suggest doing something different?

* All of this good stuff usually circulates on the Open Google group

Leave a Reply

Your email address will not be published. Required fields are marked *