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 (for the whole story on MailScanner see MailScanner: a case study in sustainability). 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 53% of institutions operate a mixed 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.
One of the main drivers pushing ICT managers to seriously consider OSS during procurement processes is that many OSS products can be considered to be 'enterprise ready'. This means that the software has been developed to a standard where it can cope with the demands and sheer scale of the implementation required by corporate companies and large organisations, and is mature to the point where it can be usefully compared with proprietary systems.
There are many factors that are important when attempting to ascertain whether software is truly enterprise ready:
It is becoming increasingly apparent that OSS solutions can deliver on these kinds of enterprise ready questions. 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).
This growing interest is supported by the UK government's Open Source, Open Standards and Re-use: Government Action Plan, which lays out clear actions for the future. Action 1, for example, is '[to] develop clear and open guidance for ensuring that open source and propietary products are considered equally.' OSS is here to stay.
Some of the most revealing insights to emerge from the OSS Watch workshop on software procurement were details of how public sector procurement practices are skewed towards proprietary software. This is partly through the way the tendering process is constructed, but also partly to do with the kinds of questions that are asked as part of the tender process, and the assumptions that are inherent in those questions (see the 'suppliers' section of the workshop report for more detail). One delegate pointed out that the very first question a public-sector procurement process should ask a potential supplier is 'Are you using open standards?'
This focus on open standards is very interesting from several perspectives. First of all, the public sector is now expected, even mandated, to procure software that adheres to open standards3. This is being driven on several levels and is something that IT managers and procurement officers need to take very seriously. There are two main factors driving this:
Both of these forms of lock-in are caused by the use of proprietary file formats that don't adhere to open standards, and are, in fact, very closely interlinked in terms of the problems they cause.
Historically, standardisation of the file formats we use has been achieved through the widespread adoption of products from a very small number of suppliers. This meant that a kind of interoperability was achieved through market consolidation and is an example of de facto standardisation: i.e. in order to be able to read and edit the files sent from other people, you have to 'join the club' and invest in the same software.
Initially this was helpful, as it meant that a kind of interoperability was achieved, albeit through market dominance rather than agreed standards. However, it has also created a form of vendor lock-in. This has become increasingly unacceptable, and government agencies, in particular, are becoming increasingly conscious of the need to provide access to data and electronic documents to all members of the public, while not requiring them to purchase a particular software product in order to view or edit these documents. The requirement to provide long-term availability of data for archiving and retrieval is also an issue, and there is a move away from proprietary file formats, particularly where future access might only be via a single supplier's software products. This is all being reinforced by policy moves from within the EU, along with parallel initiatives by the United Nations Joint Inspection Unit (Ditch, 2007).
National governments are also moving steadily towards the adoption of open standards as a means of ensuring interoperability, and in the UK, government interoperability requirements are defined by the e-Government Interoperability Framework (e-GIF)4:
'The compliance rules for these basic specifications apply to all public sector bodies…'
OGC (Office of Government Commerce) 2004b.
What's important to take note of, is that just because something adheres to open standards it doesn't necessarily mean that it is open source, and, that just because something is a proprietary product, doesn't necessarily mean that it doesn't conform to open standards5. The e-GIF does not insist on OSS being employed as such – it emphasises that decisions on whether to use OSS, proprietary software (based on open standards) or a mixture of both, can be made on a case-by-case basis. Where the e-GIF is unequivocal, however, is on the use of open standards to achieve interoperability.
While software being released under an OSI-approved licence does not guarantee that it will use open standards, it is true that it is more likely to do so. There is usually no advantage in developing a proprietary standard when the code to manipulate that standard is open source, since there is no ability to lock users in to that standard. Generally, open source software will only stray from available open standards when there is a good technical reason for doing so. In this situation, unlike in closed source, the open nature of the code makes the modifications to the standard obvious and freely available to all.
In the UK, the education communities have developed a culture that is strongly supportive of open standards, and this is reflected in the development and support activities of Becta, JISC and associated services and projects. JISC’s policy, strategy, procurement, guidance and funding criteria have developed over the years to promote the use of open standards throughout teaching, learning, research and administration as part of a three-stranded approach: open content, open standards, and open source.
This is reflected in JISC's (2007) strategy, which outlines three principles in respect of its funded projects. The second of these is a commitment to open standards that 'support interoperability between systems whether commercial or open source[,] and where available and broadly adopted, allow institutions to mix and match products of either type and to replace products without high switch costs'.
This reference to the high costs of switching software is related to data lock-in and forms a linchpin to the third key procurement driver: cost.
One of the many myths that have sprung up around OSS is that it is free of charge. 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.
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 is more expensive than, say, outsourcing a support contract, where there is a bigger marketplace to choose from. It's also important to remember that the more customisation you need and pay for, 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 kind of barrier to switching and creates a form of lock-in to the closed source software provider6.
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 7. 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).
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.
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 from 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.
Much of this document was written by Gaynor Backhouse of IntelligentContent and her efforts have contributed in large part to the excellent result.
It is licensed under the
Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
OSS Watch is funded by the Joint Information Systems Committee.