Levelling the playing field: developing a mixed economy for software procurement

by Paul Anderson, Intelligent Content on 15 May 2008 , last updated

Introduction

A report from the OSS Watch Procurement workshop held at the Saïd Business School, The University of Oxford, 18 March 2008, by Paul Anderson, Intelligent Content.

How do you procure something that’s free? This is a conundrum that is preoccupying open source software experts and public sector procurement managers, and formed the subject of Oxford University’s OSS Watch workshop held in Oxford on 18 March 2008. While open source software (OSS) is available via a licence that ensures it is provided free of charge (or at low cost), the licence cost only makes up a small part of the total cost of ownership (TCO) of an IT solution. Nevertheless, the image of OSS as a free option this is one of the many myths that have sprung up around open source and which have made it difficult to procure, particularly in education and other public institutional settings. The main thrust of the thinking at the conference was that, compared to closed source software, OSS doesn’t enjoy a level playing field when it comes to procurement.

So why doesn’t open source software get a fair deal? Part of the answer lies in the fact that, over the years, open source and free software has come to be seen as a niche product - a bit, well, geeky. There’s a general perception that it is difficult to implement, involves lots of smaller components being put together, does not scale well and is just not ‘enterprise ready’. The cost factor has also fuelled this perception. People believe that OSS is free of charge, and, because of this, that it can’t really be just as good as ‘paid for’, proprietary software. The assumption is that if OSS really were as good as proprietary software, then surely people would charge for it, wouldn’t they?

These and other myths and organisational barriers associated with open source are complicated and intertwined, and the net effect is that the take-up of OSS across the public sector has not been as high as it should be. Untangling these issues in order to level the procurement playing field formed the subject of the OSS Watch workshop, which attracted a wide variety of public sector staff, software developers and companies involved in open source solutions.

Ross Gardler, Manager of OSS Watch, opened the workshop by outlining a number of reasons why it is important to include OSS in any procurement discussions. Firstly, there is the wider strategic and ‘political’ context: a growing number of governments, educational agencies and public sector bodies are using open source and outlining recommendations and policies that mandate that it should at least be seriously considered1.

Secondly, the workshop learned that there are a number of reasons why open source should be considered on its merits. Due to its inherently open nature, OSS provides flexibility and enhanced security2. Tactically, however, just including OSS in a procurement evaluation process can have benefits, even if it’s not the final winner. Rosstold the workshop: ‘You can use it as a bargaining tool. By encouraging open source companies to enter the market place and engage with your procurement [process], you are putting pressure on those [closed source] suppliers to be better suppliers, to reduce their costs and to make their solutions more applicable to your individual needs.’

Cost

There is considerable pressure to save money on educational software procurement. Open source software is free from the most punitive licensing restrictions and the ongoing licence fees that form a considerable part of the cost of procuring proprietary software. However, it is not the case that OSS is completely free of cost. There are many additional and often indirect costs to be considered over the full life cycle of an open source application - commonly known as Total Cost of Ownership (TCO) - and these should always be factored in to procurement processes.

Matthew Dovey, JISC Programme Director, e-Research, argued that cost was one of the many myths of open source: ‘[There is a myth that] OSS is free, or sort of free, and that [we can] assume the Total Cost of Ownership is zero. [Actually] the budget headings are slightly different, but it will still cost money.’

Simon Mather, from Ufi (University for industry), discussed many of these less obvious costs when presenting his experience of migrating his institution’s technology from the proprietary Microsoft Windows ASP environment to an open source environment based on Java and Linux. He noted the direct and obvious costs of ongoing service and maintenance, but he also pointed out that with OSS the supplier doesn’t generate any revenue from the upfront licence fee. Consequently, many open source companies make a living from a variety of business models that are structured around providing after-sales services, training and documentation support.

In addition, and something that is less quantifiable, are the costs of investing in training to develop in-house expertise. This enables staff to become more than just a passive consumer of a proprietary product - so that they can both use the software and engage with the online support communities, and understand how to address the managerial challenges of working in a more agile and more proactive way. However, as Simon pointed out, these costs, while difficult to quantify, can be considered part of a long-term investment: ‘We are investing in our future. Open source really does contribute enormously to our technical capabilities and it’s not just about what we adopt in our code base. It is also about culture within the development team and that the team is working with the code and working with the community and understanding where that community is going.’

Maturity

Even if it is accepted that open source solutions should have a role in public sector procurement, it is clear that not all open source software is the same and that there are degrees of software maturity. Ross Gardler told the workshop: ‘Not all open source is equal. Just as not all closed source is equal. If [you] go to the SourceForge open source repository you would see something like 150,000 projects on there3. Although I have never done a full analysis, only a very small proportion of these projects are genuinely useful, sustainable and continuing with activity.’

What this really boils down to, is the difference between immature open source projects and well-forged, enterprise-class solutions which have an excellent community of users and developers, and a good track record of delivering a well-thought-out roadmap. However, it is worth noting that these requirements for maturity work both ways. Andy McKay, from Blue Fountain, said in the panel sessions that there is often a ‘buying chasm’ that many organisations and institutions don’t cross. They are prepared to download the free software, but then they are not prepared to engage with the development and support communities built around it, nor to employ a third-party service company to help them make use of it. This means they often fail to get the full benefit of the open source software and this may then contribute to a feeling of disillusionment with OSS.

Various speakers also pointed out that the term open source has been disputed. For example, there is something known as crippled open source, where an institution has to actually pay a licence fee for the full product, rather than use the cut-down, free to download, trial version. Mark Taylor, President of the Open Source Consortium, issued a caveat emptor message, arguing that there is a distinction between those companies that are fully engaged with the open source development ethos and processes and those whose products simply ‘have the magic marketing pixie dust on it’.

One way of getting to grips with all of this is to use one of a number of Evaluation Frameworks. These are well-documented, formal processes for this kind of decision-making and they facilitate the process of reviewing OSS and its sustainability, assessing against criteria and producing weighted scores. Well-known frameworks include: OS Maturity Model (OSMM) from CapGemni, OSMM from Navica, QSOS (Qualification and Selection of Open Source software), and the Business Readiness Rating model (BRR).

Suppliers

Much of the open source supplier and service market is made up of smaller players, and this often translates into a perception of the marketplace as being ‘fragmented’. As John Lane of Imperial College, put it: ‘One of the big barriers to open source procurement is the fear that you will not be able to interact with third parties outside your organisation if you choose something that isn’t one of the big players. [In essence it is] the old argument – “You never get sacked for buying IBM” - and you have to cross that bridge.’

One way in which this is being addressed is through the creation of consortia – groups of companies who have agreed to present their work together and who often work in partnership. However, this also works the other way around. Ross Gardler told the workshop that OSS Watch is actively ‘encouraging [educational] institutions to create an open source policy’, and this was reinforced by a member of the audience who mentioned higher and further education procurement consortia such as LUPC (the London Universities Purchasing Consortium, part of the JISC-funded Procureweb service4) and SUPC (Southern Universities Purchasing Consortium).

However, many speakers agreed that the market was changing and that, all too often, procurement processes were insufficiently flexible to handle this. Vince Blogg, for example, of Hubstone, argued that: ‘[Procurement] does need to change to reflect the way the whole consultancy market, open and closed source, is changing. Much more work is being undertaken by smaller enterprises and micro-businesses’.

This was reinforced by Mark Taylor, who was also the second keynote speaker, when he pointed out how the supply market is changing. He stated that there are a rapidly growing number of suppliers of open source software and these vary from micro-companies through to large multinationals and some of the biggest names in the computer industry: ‘Even Microsoft is having its open source moments.’

Mark was also quick to make the distinction between ‘commercial’ and ‘proprietary’: ‘[Some people] make a distinction between commercial and non-commercial companies, the implication being that open source is non-commercial. But actually the distinction is between proprietary and non-proprietary and this is what we recognise.’ His point was that it is important to be aware that open source solutions can be provided by commercial companies that are able to provide the necessary support and services (training, etc.) and who can also act as the third party in contractual arrangements.

One of the significant barriers in this respect is the procurement process itself. In order to participate in the formal invitation to tender (ITT) and tendering process (including a Pre-Qualification Questionnaire, or PQQ), potential suppliers need to know about the ITT in the first place. Michael Farman, from Alfresco, pointed out: ‘A [characteristic of] traditional software vendors is that they have large, direct sales teams whose job is partly to look for these tenders.’ This is a big challenge to the open source industry as its sales model is different and it has to be in order to be commercially viable. Lars Ronning of Zimbra, said: ‘We don’t have the sales force that is necessary to go out and track the market all the time.’

One supplier suggested that if procurement processes allowed it, then notifying companies of a forthcoming tender would help. This resulted in some considerable debate among panellists as they discussed the effect that various restrictions, such as EU competition rules, have on how far institutions can go to involve open source companies in the tendering process.

Mike Fraser, OSS Watch director, who is involved in procurement processes at Oxford, commented: ‘[We need to make sure] we don’t inadvertently put items in the ITT which may exclude OSS suppliers. In a traditional procurement [process] there is usually quite a number of pages about the company and its turnover, what’s the likelihood that it will not go bust, before you get to the functional requirements.’

This focus on company structure is therefore sometimes made at the expense of the assessment of skills and ability to do the job. It also doesn’t take account of the fact that the software is developed as a community, and how should one measure the ‘corporate structure’ of a virtual, open source development team?

Levelling the playing field

So, given that there are barriers within institutions to the procurement of open source, and given that it should be considered, what are the recommendations or ways in which institutions can improve their processes? How can the playing field be levelled? A number of recommendations came out of the keynote speakers and panel discussions.

One of the key recommendations came out of a discussion around the importance of open standards and long-term migration of data. Boris Devouge, from RedHat, argued passionately that: ‘One of the very first questions when using public money should be: Are you using open standards? Is my data safe? You need to know that [with] the solution you are advocating now, [that] in ten years’ time it’s not going to cost forty times as much to migrate the data somewhere. This is so often overlooked in the procurement papers that I receive from government, schools, universities [asking us] to field a request. It should be the number one question. [At the moment], the first five or six questions are what is your licence, do you provide site-wide licence, etc. The process, right from the start, is based on closed source software. This needs to evolve.’

Other recommendations included:

  • better communication with senior managers across HE/FE as to the potential benefits and pitfalls of making use of open source solutions5

  • further efforts should be made to engage with consortia such as LUPC and SUPC in a formal process. It was also felt that educational institutions should engage with the consortia being formed by commercial open source solution providers to help them to understand the special requirements of education so that their members could engage with the procurement process.

  • educational ICT bodies with an overview of the sector such as UCISA and BECTA should assist institutions with the training and knowledge required to improve the levels of access for open source solutions and companies. Work could be undertaken to improve the ITT and the pre-purchase questionnaire (PPQ) processes within institutions. It was felt that a good place to start would be to review the ITT.

To sum up, the general feeling was that procurement staff need to be better trained in what open source is, why it can help deliver a better solution, how its inclusion in a procurement evaluation can sharpen the bids from closed source companies and, in particular, issues to do with data migration and long-term costs.

Matthew Dovey encapsulated this neatly: ‘We [JISC and OSS Watch] don’t wave a banner saying OSS will save the world. We want to advise the sector on the true issues when it comes to choosing open source versus closed source so that we have a level playing field and so that the software that is finally chosen is chosen on its merits and not on any religious faction. What we want to see ultimately is a mixed economy.’

Further reading

Links:

Related information from OSS Watch:


  1. Part of the reason for this is that OSS usually conforms to open standards and this is now becoming a requirement for software bought with money from the public purse.

  2. It is argued that because the code is publicly available, problems are quickly identified and rectified by the wider development community.

  3. http://sourceforge.net/ listed more than 230,000 in February 2009.

  4. http://www.lupc.procureweb.ac.uk/about/index.shtml

  5. The latest national survey of open source use in HE/FE (from OSS Watch) is the kind of thing that higher management are interested in.