Decision factors for open source software procurement
by OSS Watch on
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 projects1, 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 75% of 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 QuinetiQ2 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.”
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 institution.
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 institutional ‘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 institutional 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 institutional 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 institution 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 3. 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 institution. 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.
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 institution, 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 institution 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 institution’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 institutions 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.
- Becta. 2005a. Open Source Software in Schools: A study of the spectrum of use and related ICT infrastructure costs. download archived PDF
- Becta. 2005b. Open source software in schools: A case study report. download archived PDF
- Ditch, W. 2007. XML-based Office Document Standards. Available online at: http://www.jisc.ac.uk/media/documents/techwatch/tsw0702pdf.pdf
- JISC. 2007. JISC Strategy 2007-2009. Available online at: http://www.jisc.ac.uk/aboutus/strategy/strategy0709.aspx
- OGC (Office of Government Commerce). 2004a. Open Source Software Trials in Government Final Report. Available online at: http://www.ogc.gov.uk/documents/CP0041OpenSourceSoftwareTrialReport.pdf
- Open Source, Open Standards and Re-Use: Government Action Plan (pdf) [http://www.cabinetoffice.gov.uk/sites/default/files/resources/open_source.pdf]
- Peeling, N. and Satchell, J. 2001. Analysis of the Impact of Open Source Software. Available online at: http://www.cabinetoffice.gov.uk/govtalk/archive/policy_documents1_of1/open_source_policy_archived_docs/analysis_of_the_impact_of_open_source_software.aspx
- Woods, D. and Guliani, G. 2005. Open Source for the Enterprise: Managing Risks, Reaping Rewards. Sebastopol, CA, USA: O’Reilly.
- Bacon, S. and Dillon, T. 2006. The potential of open source approaches for education. Available online at: http://archive.futurelab.org.uk/resources/publications-reports-articles/opening-education-reports/Opening-Education-Report200
- Wheeler, D. 2005. Why Open Source Software/Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! Available online at: http://www.dwheeler.com/oss_fs_why.html
- JISC sustainability study [http://www.jisc.ac.uk/media/documents/programmes/distributedelearning/sustainabilitystudy-1%5B1%5D.0.pdf]
Related information from OSS Watch:
- Open Source Options: Making use of the Cabinet Office guidance on Open Source Software
- Software Sustainability Maturity Model
- Levelling the playing field: developing a mixed economy for software procurement
- Procuring Free & Open Source Software
- Top Tips For Selecting Open Source Software
- The JISC Virtual Research Environment Phase Two Programme: Attitudes to and Awareness of Open Development
- From a trickle to a flood: building wide open communities in open source - Community and Open Source Development Workshop, Oxford, 20 October 2008
Much of this document was written by Gaynor Backhouse of IntelligentContent and her efforts have contributed in large part to the excellent result.
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↩