Decision factors for open source software procurement

by The OSS Watch Team on 11 July 2008 , last updated 11 April 2014

Introduction

Organisations are inreasingly recognising the role free and open source software plays in their IT portfolio, and modifying the way in which they procure software and services to ensure they are not inadvertently excluding open solutions. Many IT departments now operate policies that either mandate equal consideration of open source, or even a preference for open source over proprietary solutions. In this briefing we’ll outline some of the reasons benhind this.

If you’re involved in procurement, you may want to review the presentation below given by OSS Watch. If you’d like us to deliver a similar workshop at your organisation, let us know.

Download these slides here: ODP PPT

Open source software in context

Towards the end of 2000, a message was posted to the uk-mail-managers list, hosted at Newcastle University, alerting people to the fact that there was a new piece of anti-virus software available. A few people tried it out and liked it, because it deleted infected attachments from email messages and delivered as much of the message as possible. This was an improvement on existing systems, which deleted the whole message if they found an infected attachment.

Interest in the software grew, and within six years, MailScanner, as the software was called, became one of the world’s most widely used email security and anti-spam systems. It has been installed in many prestigious institutions including the US Navy, HP Labs, MIT, BAE Systems and Harvard Medical School. In Europe, every email, SMS and Multimedia SMS sent from a Vodafone phone goes through MailScanner. And MailScanner is an example of open source software (OSS), released under an OSI approved licence.

There are many such stories about successful OSS projects¹, and, increasingly, public sector-funded bodies are being encouraged or even mandated by EU and UK governments to consider the use of OSS (OGC, 2004b). For IT managers within education, as with the rest of the public sector, there are numerous opportunities to procure and install OSS systems or components as new installations or upgrades are required — whether a new desktop learning suite, a server upgrade or site-wide database project. Indeed, most IT managers will already be operating in a ‘mixed environment’ of open and closed source software systems.

In the UK higher and further education sectors 100% of HE institutions and 50% of FE institutions operate a mixed server environment. So why is OSS still often overlooked as a mainstream procurement option?

Part of the problem is in understanding what exactly is being procured: a lack of clarity about the way in which OSS is produced and deployed, resulting in part from a shortage of skills in this area, has led to fears about its long-term sustainability. In addition, many of the OSS systems currently in use within education and the wider public sector have been adopted in an ad hoc way, rather than formally procured. In fact, the ‘how’ of procuring OSS is quite different from the standard ITT-based process used for proprietary (‘closed source’) software. While structured and co-ordinated approaches are being taken to address this, getting to grips with all the issues can be quite resource-intensive for those embarking on it for the first time.

What’s important to remember is that there are some pretty compelling reasons why OSS should at least be considered in the technology procurement landscape. This briefing paper will summarise the key OSS procurement drivers around three concepts: enterprise readiness, open standards, and cost versus investment.

Key factor one: OSS has a proven track record

The myths about OSS being unreliable, unsupported code made by hobbyists and unsuitable for business-critical applications have long been dispelled. OSS products have as varied ecosystems of development and support as their proprietary counterparts. Reports and case studies have shown time and again that OSS solutions are suitable for deployments where business-critical factors such as support, security, scalability and integration are paramount. With this understood, it is impossible for IT managers to ignore OSS as a serious option during procurement processes.

Over the last few years there have been several, authoritative studies that confirm the credibility of OSS:

The QuinetiQ² report (Peeling and Satchell, 2001) determined that OSS is a ‘fundamental change in the software infrastructure marketplace, and is not a hype bubble that will burst’, and that OSS offers a ‘new paradigm for funding software’ in the Health and Education communities.
In 2004, the UK Government’s Office of Government Commerce (OGC) carried out OSS ‘proof of concept’ trials in a range of public bodies and concluded that: ‘Open Source software is a viable and credible alternative to proprietary software for infrastructure implementations, and for meeting the requirements of the majority of desktop users’ (OGC, 2004a).
Another OGC report confirms that OSS ‘has leapt to prominence by starting to take a significant share in some specific parts of the software infrastructure market’, and that ‘unlike some new developments which fail to live up to the hype, OSS is indeed the start of a fundamental change in the software infrastructure’ (OGC, 2004b).
Open for business, The value of Open Source Software in trasaction processing (Norton 2012) which we reported on in detail. Norton notes that open systems provide businesses with access to greater innovation, improved supplier responsiveness, and enhanced system accessibility compared to proprietary equivalents.

This growing interest is supported by the UK Cabinet Office’s Open Source Procurement Toolkit, which is designed to “create a level playing field for the use of innovative ICT solutions” by providing “a toolkit for procurers on best practice for evaluating the use of open source solutions.” OSS is here to stay.

Key factor two: the importance of open standards

Adherence to standards is an important factor when procuring software. By ensuring that procured software supports relevant standard file formats and data models, you reduce the risks and costs associated with migrating to an alternative solution at a later date.

When discussing standards, it’s important to realise that some standards are difficult to implement in OSS, due to licencing royalties, patent contstraints, or simply because they’re de facto standards which aren’t openly defined, so must be reverse-engineered from existing implementations. The implementation of standards in OSS is discussed in detail in our briefing note on the subject.

The UK Government ICT Strategy (March 2011) committed the Government to creating a common and secure IT infrastructure based on a suite of agreed, open standards. To ensure a level playing field for all software vendors in the UK public sector, the UK Cabinet Office has published its Open Standards Principles in which it defines an open standard as a standard where, among other things, “rights essential to implementation of the standard, and for interfacing with other implementations which have adopted that same standard, are licensed on a royalty free basis that is compatible with both open source and proprietary licensed solutions.” From 2012, all UK Government bodies were required to comply with these principles.

Where a standard has been adopted, there are some key considerations when procuring an OSS solution:

Transparency: An OSS solution allows you to freely install and test the software to ensure it adheres to the standards as advertised. You can also inspect the source code behind the implementation.
Flexibility: The terms of proprietary licences may prevent you from implementing alternative formats or integration between the proprietary solution and other systems. OSS licences contain no such restrictions.
Contingency: Even where an OSS solution doesn’t implement a particular standard, you will have full access to the data model, mitigating the risks and costs of migrating to another solution, or adopting an alternative standard.

Key factor three: Cost versus investment

One of the many myths that have sprung up around OSS is that it is free of cost. Although there can indeed be significant up-front savings in using OSS (because there are no licence fees), it certainly cannot be considered to be cost free. This is because over the lifetime of use of the software there will be a number of internal costs (e.g. staff training, upgrading hardware and networks), and possible external costs (e.g. through the use of third- party support and maintenance). These are known collectively as the Total Cost of Ownership (TCO).

On this basis, cost may seem to have lost some of its appeal as a procurement driver. However, it’s important to remember that while these costs are sometimes hidden and can be difficult to quantify at the beginning of the procurement process, many if not all of them will also apply to any proprietary solution that is implemented. Once these costs become visible, the debate becomes about how best to spend the money. With third-party closed source software, there is only a restricted choice: on a spectrum of costs that ranges from fully self-supporting (all work is carried out in-house) to fully outsourced (all work is undertaken by third parties), closed source software requires IT departments to operate at or near the fully outsourced end of the spectrum. With OSS there is more flexibility: IT departments can choose how much they want to outsource and how much they want to do in-house. This means that the TCO can be leveraged as a budget, to create longer-term investment value for an organisation.

An understanding of this is key to appreciating the overall attractiveness of OSS. There are three key areas that demonstrate how the way in which OSS is ‘done’ can release the value of a ‘cost’ into an organisational ‘investment’. These key areas are code, customisation and community.

Code and customisation

Software solutions rarely match an organisation’s needs perfectly. Other than change the organisation’s business processes to fit the software, there will inevitably be a necessary process of configuration and possibly even actual adaptation of the software in order to fit the local domain.

With closed source software the only option is to pay the developer of the product to make adjustments in a later release, or local customisation of the software. The pool of people who are allowed to carry out this kind of work is usually limited, so customisation may be more expensive than, say, outsourcing a support contract, where there is a bigger marketplace to choose from.

Open source software provides the opportunity for the organisation’s IT department to use their expertise to adapt the source code to make the software fit the local conditions. However, without careful management this type of customisation is not without its own set of problems (it may hamper upgrades, for example). When using OSS, an organisation is more likely to have some measure of control in overcoming these issues. For example, local customisations can be contributed back to the open source project in order to facilitate the product’s development, while at the same time simplifying local upgrades ³. Alternatively, an organisation may choose to participate in the open source project’s community, as a user, in order to highlight the need for specific changes. While this type of activity still requires a financial commitment (e.g. to staff training), the investment stays in-house and can be recycled in other ways. For example, an increased level of expertise allows for the development of more in-house user support services or better internal user documentation.

In addition, having access to the source reduces the risk of systems becoming obsolete if a supplier disappears from the market, or of users being forced to migrate to a new product (e.g. after a business take-over or when a proprietary provider withdraws support for an older version).

Regardless of whether you use open source or a proprietary system, the more customisation you need, the more the system costs the organisation. Over a period of several years, these costs add up. This means that when you come to evaluate whether or not to keep going with the existing software or to switch to a different system (perhaps a newer, better one that wasn’t around when you made your initial decision), it can often seem cheaper to persevere with the existing system just because you’ve already invested so much money in it. This cumulative spend forms a perceived barrier to switching and creates a form of lock-in when using a closed source software provider. However, if the closed source software in question is based on open standards, switching costs should be lower, as the cost of migrating data should automatically be reduced. When using open source software, all standards used are almost exclusively open and provide you with this flexibility. Additionally, you have more options when considering switching to a new system. Because you have access to the source code and the data is stored in a way that it can more easily be extracted, you can replace only parts of the system and more easily trial other systems.

Permissionless innovation

One of the other key characteristics of FOSS is freedom, and this is emerging as an important consideration when using software to deliver key user-facing services.

Organisations increasingly identify the importance of “delivering constant value and incremental improvement” that can be delivered through participation in FOSS projects, and through permissionless modification.

While it may seem at odds with typical procurement and deployment practices, where software is used for delivering key services to customers, organisations can choose to devote resources to continual innovation and improvement (using agile processes and continuous testing) rather than more traditional models of sparse planned service upgrades. This can make the difference in crowded markets; or for public sector, react to public demand. With FOSS, continual service improvement processes can be implemented in an agile manner.

For example, at the Open Source Open Standards conference in London on April 3rd, 2014[^8], James Stewart from the UK Government Digital Service (GDS) stressed the importance of the permissionless character of FOSS. This enables GDS to modify government frontline services whenever there is need, or whenever an improvement can be identified. This means that services can innovate and improve continually without requiring cycles of negotiation with suppliers.

Community

In the context of OSS, ‘community’ is often mistakenly used to refer to the software development community that builds up around a particular software application. However, by looking at examples of more mature OSS developments such as Moodle, ‘community’ reveals itself as being much broader than this, incorporating an ecosystem of users, commercial developers and support companies to which work can be outsourced (for more information on how Moodle does this see Moodle: a case study in sustainability).

In proprietary software scenarios, a commercial support agreement is entered into, either with the developer (i.e. the vendor) or with a third-party service provider, and this provides ready access to a team of support professionals who help to ensure that the software that has been purchased works the way it is supposed to work. This kind of support usually means the procuring IT department has the comfort of ready access to a phone number to ring for help and to report issues.

For some IT departments, this may be the preferred option – to outsource support and development work so that there is only ‘one throat to choke’ (Woods and Giuliani, 2005). The fact that the cost of this may form a substantial part of the TCO and that it might lead to another form of lock-in, is less important than the peace of mind that comes from knowing that there is a third party out there being paid money to support them.

With some OSS, this kind of support is available from the product vendor. For example, Sun (Open Solaris), SugarCRM and Alfresco are all significant companies providing centralised product support similar to that found in the proprietary world. However, some other OSS projects, such as the Apache web server or GNU/Linux, have no commercial owner, and hence no central body to approach for support. But this doesn’t mean that the support isn’t there. In both types of open source, there is a burgeoning third-party support industry, including consortia of companies who have agreed to present their work together and who often work in partnership.

In order to release some of the value of the costs of OSS back to the organisation, it’s important to be pro-active. Staff training, for example, not only contributes enormously to the level of technical skill needed to deal with the code, but also generates a culture within the development team, in that they are working with each other and the code, and also working with the OSS community and formulating an understanding of where that community is going. The extent to which an organisaion might want to venture down this ‘self-supporting’ route is a matter for individual consideration, but it is an option that only OSS can offer.

The real value of OSS: options and flexibility

Historically, discussions around the advantages of OSS have focused on its cost, or rather its perceived lack of cost, based on the fact that there are no licence fees incurred in using it. While it is true that OSS can potentially deliver a reduced ‘whole of life’ total cost of ownership, and provide a viable and credible alternative to propriety software (see, for example, Becta 2005a and 2005b for a comparison of schools using OSS with those using proprietary systems), these are arguably not the main reasons for choosing OSS.

In fact, the real value of OSS is that it makes it possible for you to exercise control over how you run your organisation’s IT department by allowing you to choose a model on any point on the spectrum that runs from fully self-supporting to fully outsourced. In turn, this allows organisations to choose the extent to which they want, and are able to, take advantage of the strategic organisational gains that accrue from the use of open data standards and open source software.

Acknowledgements

Much of this document was written by Gaynor Backhouse of IntelligentContent and her efforts have contributed in large part to the excellent result.

There are more case studies of successful, large-scale OSS developments at the case studies index page ↩
QuinetiQ is one of the largest defence research organisations in the world and was formed from the larger part of the former UK Government agency DERA when it was split up in June 2001. It develops innovative technologies for Government organisations such as the UK MoD and the US DoD. ↩
Martin Dougiamas, the founder of Moodle, ascribes the frustration he experienced getting the changes and bug fixes he needed for closed source software as a key motivation behind starting Moodle. See Moodle: a case study in sustainability ↩

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.