Lists of open source alternatives to proprietary software packages

Earlier this year, the British Cabinet Office refreshed its Open Source Procurement Toolkit, which includes a list of 'Open Source Software Options for Government'. The document includes over 150 software packages, each with a short description, the names of some proprietary packages it might replace, and links to case studies.

The list can be used to inform the design of new IT solutions, to suggest opportunities for IT service or solution refreshes, and to challenge proposed solutions that do not use open source technology. In this case study we first discuss the UK government's list of open source options, followed by four interviews: Tariq Rashid, responsible for Strategy & Change at the Cabinet Office; Scott Wilson, Service Manager of OSS Watch at the University of Oxford; open source expert Pia Waugh; and IT consultant Emidio Stani. Finally, we present the OSII stack, a German range of open source software applications, guaranteed and certified to work together.

Open Source Procurement Toolkit

The Open Source Procurement Toolkit was made available in October 2011. It was one of the actions defined in the Government ICT Strategy (in PDF format) published in March 2011. The toolkit was introduced together with the Strategic Implementation Plan, which focuses on standardising government ICT.

Open source, unfortunately, is only a small part of this plan: "For all relevant software procurements across government, open source solutions will be considered fairly against proprietary solutions based on value for money and Total Cost of Ownership (TCO). Success will be measured initially by a survey of each department's compliance with the existing open source policy. Longer term, open source usage will be measured annually by the use of a departmental maturity model. The ICT Asset and Services Knowledgebase will be used to record the re-use of existing open source solutions, and the deployment of new open source solutions."

Open Source Software Options for Government

The toolkit provides procurers with best practice for departments to evaluate and adopt open source solutions, aiming to create a level playing field for open source and proprietary software providers competing for government IT contracts.

In April 2012 the toolkit was updated and extended; it now contains nine documents which should make it easier for SMEs selling open source solutions to compete for government contracts. "The information in the toolkit aims to let people know that there are other solutions out there, and to give procurers the information they need to fairly evaluate all options," Niki Barrows, member of the Strategy & Architecture Team at the Office of the CIO of the Home Office said previously.

A list containing dozens of open source software alternatives to proprietary applications has been published as part of the procurement toolkit. "While the kit does contain a list of open source options — a list of products which can be considered as alternatives for closed source products — this list is not prescriptive or definitive and is in no way a list of pre-approved or selected software," Barrows emphasized. The list was one of the documents updated in April 2012.

Over 150 software packages

The list of options contains only two introductory pages; the vast majority of the document consists of details of over 150 software packages, each with a short description, the names of some proprietary packages it might replace, and links to case studies.

For example, MySQL is presented as an alternative to Microsoft SQL Server, Oracle Database and IBM DB2. The accompanying comments state that the software is long-established and proven, that it's a component of the established LAMP stack, which in turn supports many common deployment patterns including Joomla, WordPress and Drupal, and that MySQL was historically not designed to be feature rich but instead is optimised for read speed. The references include Google, Facebook, Flickr, Wikipedia, Nokia, Youtube, Twitter, NASA, the United Nations, the US Navy, Whitehouse.gov, the New Zealand Ministry of Justice, Ericsson, Cable & Wireless, and the new www.gov.uk site.

The packages are subdivided into seventeen categories:

1. Infrastructure and Server;
2. Data and Databases;
3. Middleware;
4. Application Servers;
5. Application Development and Testing;
6. Cloud;
7. Business Applications;
8. Network;
9. Web and Web Applications;
10. Geographic and Mapping;
11. Security Tools;
12. Desktop Office;
13. Specialist Applications;
14. Education and Library;
15. Health;
16. Service Management;
17. Agile Development and Project Management.

Usage and aim

The introduction to 'Open Source Software Options for Government' states that the list "presents suggestions for open source software to be considered for new IT solutions to meet business requirements, or as replacements for existing closed proprietary software. The primary audiences for this options list are technical and enterprise architects, commercial/procurement officers and project managers within the civil service, and those from the supplier and integrator community who influence the design and make-up of ICT solutions to government. Customers and suppliers in the wider public sector are also encouraged to make use of this document."

"The set of options can be used to inform the design of new IT solutions, to suggest opportunities for IT service or solution refreshes, and to challenge a proposed solution that does not use open source technology. The document, however, does not present a list of pre-approved software. It does not remove existing requirements for due diligence and assurance on the part of government. In particular it does not transfer any technology risk from IT integrators and suppliers to government, where it has previously been contractually placed with those suppliers and integrators."

The authors aim to "present options for open source software for use in government, while recognizing that open source software is underused across government and the wider public sector. The set of options is primarily intended to be used by government to encourage IT suppliers and integrators to evaluate open source options when designing solutions and services. It does not, however, imply preference for any vendor or product. Even though the open source ecosystem is a rapidly developing environment and any options list will be incomplete and may become outdated quickly, given the relatively low level of open source experience in government, this options list has proven useful for encouraging IT suppliers to consider open source, and to aid the assurance of their proposals."

Starting point

"The list of open source alternatives tries to address several issues," says Tariq Rashid, who is responsible for Strategy & Change at the Cabinet Office. "The IT staff at the departments were not familiar with open source: they did not know what it was, and they could not tell a good package from a bad one. That makes them unable to engage in the market and challenge an IT supplier on technical capability, value for money or strategic alignment. So it's a problem in the demand organization that we take very seriously, but one that we are not able to solve quickly. We do make good examples of open source software available. However, it's not a mandated list; it's purely to encourage discussion and debate. The reason is simple: we cannot mandate or recommend a specific product without knowing the requirements for a particular project."

"The list is really useful to our IT buyers, as it allows them to look at the wider market, including open source. It's not only a list of names with a short description; it contains links to references, news and stories about the software. So people can see where this software has been successfully deployed, and it helps them to consider some of these options. They can use it as a starting point."

"Our outsourced IT suppliers generally choose the technology for us," Tariq continues. "But the normal process allows us to challenge their proposed IT solutions if we think there may be issues around performance, or we think the solutions could be done at better value for money. The process is generally known as assurance, and this list of open source software options strengthens it."

"Now you can tell your supplier: 'So you want to sell me this web-server. Well, why are you selling me this expensive one when I can use a different technology?' The buyer can then use this list and say 'This package has been used significantly by other similar organisations; tell me again why I cannot use it.' So it helps you to challenge the supplier."

Maturity

The criteria Rashid's team used to evaluate the maturity and deployability of the packages on the list were very broad, but all the software had to be proven in three areas:

1. Scale: "If something is working, processing, or being used millions of times per day, perhaps used by airlines to process critical transactions across the globe, that is large-scale. That should give you some confidence that it will work at that scale."
2. Criticality: "If we can find examples of software being used in critical functions, like healthcare — when a patient's health depends on it — or if it's used in real-world operations by crime agencies, or in high-security environments, then we can say that this software can be made suitable for critical systems."
3. Longevity: "If a package has been working successfully for twenty, thirty years, then it can be added to the list, because then it's not new and unknown. If it has been in operation for many years, we know the risks."

"The reason we were not too specific about the criteria is that otherwise we wouldn't have been able to publish it," Rashid explains. His team took a very practical approach. "We did not get too specific or scientific about it, because then we would have to start arguing about what is and what is not allowed on the list. So we did not perform a full maturity check. We used the experience and knowledge of those that have been in the open source market for a long time, that way closing the gap between those who are familiar with the open source ecosystem and those who are not. And when an open source supplier comes to us, asking to be on the list, we can say 'Yes, that's fine. Please send us some examples, so we can say that you indeed meet one of the three criteria.' Getting the definition right on what is included and what is not, is not overly important, for a list of suggestions; practical common sense is more important."

"We find that it is working better than we expected. People are referring to the list, our colleagues are challenging their suppliers, and the open source suppliers want to put their software on the list. So we hope to continue updating it every six months to a year. We have had two versions out already, and we have some feedback for the next release."

Across Europe

In the meantime Rashid is also working on some other ideas. "The current list is not in its best form, since it's a document now. It might be better to have some kind of search engine and maybe a web application. But we wanted to get something out there very quickly."

Furthermore, the current list consists mostly of generic packages, covering traditional open source application areas like infrastructure, technology and middleware. "We started with the products and technology components, because that needed the most attention. But we would like to evolve work to document good solutions or technology patterns both for generic IT requirements, such as case-working, and for specialised sectors such as healthcare and education. We are very open to working with others to improve this list and documenting open source technology patterns, and we have no problem with others taking it and using the list themselves."

"I'm sure it can also be used across the European public sector and beyond. I don't think the software on the list is too specific, causing problems with national policies or regulations. So if people want to reshape it or reform it on a European level, then we are very happy to work with them."

Design patterns

"But the most interesting feedback we have had is that it is not actually the individual technology that is most useful. It would be more helpful to have a catalogue of design patterns. For when people want to do IT, they don't necessarily say: 'I want a web data form' or: 'I need a record management system'. They want something that solves a business problem, and that leads to higher level requirements for technology such as a case working system or a document collaboration system."

"And those things are composed of several technologies working together. So a case working system might have a storage system for documents. It might have a workflow system. It might have an application form engine. And it might have an event triggering system. All those parts working together will make the case working system."

"On the demand side we don't have a lot of experience in making these technologies work together. That's why we need to start understanding open source design patterns and solutions that are known to work well. It will be more difficult to do, but it will be more powerful as well. That way we will be solving real-world problems."

OSS Watch

One of the potential users of the list of open source options is OSS Watch, an independent organisation providing advice and guidance specifically on the use, development and licensing of open source software in higher and further education.

"We are not really in the business of offering lists of recommended applications," Scott Wilson emphasizes. He is the Service Manager of OSS Watch at the University of Oxford, and a committer at the Apache Software Foundation. "For one thing we are a non-advocacy service, which means we provide information about open source software, but we do not promote it over closed source. We would expect our community to evaluate software on a wide range of characteristics, and whether it's closed source or open source is just one of them. By providing a list you may be signalling an assumption that they have already decided not to select a closed source solution, or have separated the selection processes for closed versus open source."

"So in terms of how we would use lists like these, I'd say we would include them in frameworks such as our Software Sustainability Maturity Model (SSMM) as a shortcut for when these products come up as part of exploring and narrowing the solutions space. For example, using SSMM you may have narrowed down the field to seven 'silver candidate' products. If four of these were already on the public approval list, you might then only conduct a detailed analysis of the sustainability of the remaining three. However, you would not just drop the other three as they were not on the list, or were not open source, and you would not just accept the ones that were on the list without looking into them further."

Selection process

"Our customers are both users and creators of open source software," Wilson continues, "so their needs vary. However, in general they are looking more for advice on the process of selection and procurement of solutions and services rather than a list of products. When we are asked about specific products, it tends to be for use cases that are more specialist than the packages on this options list. In many cases they are aware of the most obvious open source projects for general purpose use, but what they need is a methodology they can use to help with selection."

"For example, within the SSMM such lists of recommended projects can be used when assessing evidence of sustainability. However, it's not sufficient simply to point to the presence of a software package on an approved list during procurement. You still need to integrate this into the wider process of identifying the set of solutions to consider, and the criteria for assessment. Also, not all solutions are equal in all areas: while solutions on a recommended list may all score highly overall for sustainability, they will vary across many of the dimensions that are analysed using the SSMM."

Context for use

So, according to Wilson, how to use the options list is more important than the actual packages that are on it: "I think you have to look at the criteria and methods used before making any judgements about the content. The Cabinet Office document has a very good introductory section and notes which set out how it was developed and the context for how it should be read, which at this stage is a number of suggestions for asking better questions of suppliers."

"For example, the document states that: 'The broad criteria for open source software to be listed in this options set is that there should be a realistic opportunity for use in government. Proven significant use is a key factor, where "proven" can mean use at large scale, volume or high performance scenarios, use in critical functions, such as supporting health or security, or long established history of use, perhaps over many years. The software should also be commonly recognised as open source, primarily aligned to the OSI definition.' With the caveat: 'If specific open source software is not listed, it does not necessarily mean that it is unsuitable for government.' My main worry is not that there is a mistake in the software listed, but that readers might not take the time to read the introduction and notes and therefore use the document's information inappropriately."

Software assessment

Wilson would therefore like to see more focus on the context and process around selecting software that includes open source, rather than more packages on the options list. "A list should be a starting point, not an end point. There are many other places to go, and people to consult. For example, in colleges and universities there are people within the organisation who bring their own knowledge and experience. There are also agencies in the UK such as ours and the Regional Support Centres (RSCs) that can help."

"At OSS Watch we're more interested in providing colleges and universities with frameworks they can use themselves to improve selection process, rather than saying which software — whether open source or closed source — they should use."

"We tend to focus on helping customers assess open source packages for themselves, whether that is for basic procurement and use, or active engagement. For example, how they might best interact with the existing user and developer communities around a project, or how to contribute local customisations upstream to avoid facing issues with applying updates later. We assume that in terms of specialist functionality, the customer is usually much better placed to assess a solution than we are. What we bring to the picture is a deeper knowledge of open source communities and practices."

Use patterns

Wilson has mixed feelings about the move from individual packages to use patterns. "Software architecture can seem a bit faddish, so being wed to particular architecture patterns may not be the best idea. I can also see it getting bogged down in arguments and counter-claims much more easily than, say, a simple suggestion that Ubuntu can be an alternative to Windows 8."

However, he does see an opportunity for a list covering more vertically oriented applications. "We should be more active in identifying open source solutions that are a good fit within verticals and which are ready for wide deployment. For example, in education I have been looking at areas such as interactive whiteboard software, lecture capture, and assessment management recently, and identified some excellent open source solutions that deserve wider attention."

"However, I don't think it's quite as simple as making a big list of 'good software' and having managers pick from it. In a previous role I worked on a UK procurement framework for school systems, and although the framework was specifically designed as a starting point for specifying local requirements, in the end local government agencies just took it as-is and used it without very much reflection. In other words, they were far too willing to accept the judgement of external experts and to give up their own voice and to ignore local demand."

"This is a major drawback with official lists. You can imagine a situation where a local expert identifies a very interesting solution that would be an excellent fit for what's needed on the ground, and then someone in the admin department says: 'Oh, that's not on the list' and selects something that fulfils a completely different purpose but has a similar-sounding name."

"It is worth noting that the Cabinet Office document identifies its main purposes as being to inform the design of new IT solutions, suggest opportunities for IT service or solution refreshes, and challenge proposed solutions that do not use open source technology. It then goes on to state that it is not intended to be a list of pre-approved software. So I think the team at the Cabinet Office are very much aware of these issues."

Vertical applications

Wilson sees no problem in vertical applications becoming more country-specific and depending on national legislation. "Some of the most national-specific areas are how organisations report to and are funded by government agencies," he says.

"This means that many of the administrative systems in education organisations are country-specific solutions, or rely on local adaptations. So open source projects in this space have also typically been nationally targeted. For example, there have been open source solutions for student administration developed in Germany and the US that do not fit the UK market, or would require a great deal of additional work."

"That said, I think this is an area which could offer very significant returns on investment in open source for schools, colleges, universities and government. However, it is also particularly challenging, because the market has very well established incumbents with their own closed source supplier ecosystems."

European level

Since the present options list essentially consists of generic packages, there is currently no reason to limit its use to the UK. Public agencies in other European countries could deploy it in a very similar way — an argument to maintain a list like this on a European level.

"In some ways this is a bit like the argument for ISO 9000 and similar standards," Wilson says, "that by making such a list you provide a basic level of trust that can be a starting point for selection and procurement, both of software and of services that rely upon it."

"The danger, however, is that you put too much attention on what is in and what is out, and create barriers to both uptake of solutions and innovation. Just because a piece of software has not been evaluated by a government and put on the list does not actually mean it is not ready for the purpose you want to use it for in your organisation. There is a real risk that if procurement processes become too fixated on published approved solution lists, then you may be excluded from being able to select alternatives and procure services for it."

"Keeping such lists up to date is also problematic, and assumes there is resource available on a continuing basis to review the latest developments and revise the list accordingly. Given those risks, it is crucial that the methodology used for creating these kinds of lists is transparent, and does not just rely on reputation or popularity."

"On the plus side, however, it makes a great deal of sense to coordinate knowledge and expertise on open source for the public sector across Europe. So if information such as lists of open source software alternatives and useful resources on a European level were combined with access to expertise and support on a national and regional level, it could have a very positive impact."

Open source resources

The OSS Watch website carries a lot of information on open source: explaining what it is, making people familiar with it and arguing why they should use it. "The briefing material on the website is very much a distillation of the answers we give to common questions," Wilson explains. "It streamlines our consultancy process, in that we can point people to primer documents that can cover some of the introductory issues before we discuss their individual issues. Therefore, taken on their own the documents can seem fairly introductory."

"We tend to respond to demand. Last year our focus was on producing more briefings on communities and governance, as this was one of the main areas we were being frequently asked about. Whereas in the coming year it is likely to be more procurement and selection."

"The people in our sector are in different places. So we provide a spread of materials and services, including introductory material for decision-makers, information on processes, governance and licensing for technical project managers, and technical information for developers."

Overcoming fears

Wilson agrees that the options list is one of the resources that can help public IT managers to overcome their fears, since using open source software instead of proprietary products is still perceived as a risk. "It can help set a more positive tone, particularly within the public sector, by showing that government is actively considering the value of open source solutions."

"I think this item is important in the introduction to the Cabinet Office list, as one of the uses of the document: 'Challenge a proposed solution that does not use open source technology.' Basically, you can use a list like this to challenge a supplier as to why they haven not considered the obvious alternatives when developing a proposal. I think this is a very important — and practical — intervention to make in procurement."

"Of course, it can go both ways too. You may ask a supplier why they have put Bugzilla down but not considered JIRA, or recommended Apache and not IIS."

"On the other hand, I certainly would not just rely on a list of 'government approved packages' before selecting software for my organisation, and I do not see why IT managers in universities, colleges and companies ought to behave any differently. A better strategy is to give IT managers the training they need to make their own assessments of risk. The SSMM provides a range of tools that managers can use to be very specific about the risks associated with particular software, whether open source or closed source, and we are working with partners to deliver this training to organisations in our sectors."

Interoperability

The policy-makers themselves have a similar fear: they are cautious about tagging open source packages with an official status or recommendation, being afraid that closed source companies will complain or sue. Yet the link from interoperability through open standards to open source seems easily made, especially since proprietary software companies avoid or tweak open standards to create lock-ins that cost governments dearly. Wilson, however, is not so sure about this relationship. "Yes, the link between open source and open standards is easily made. But I think this is unfortunate, since the argument that closed source is intrinsically worse on open standards does not really hold up to scrutiny. It may have some truth to it in a general sense, but all too often falls down when you look at specific areas of interoperability and solutions."

"It is fair to say that with open source it's easier to verify standards compliance and test interoperability. However, I know from my experiences in W3C (the World Wide Web Consortium) that open source companies and projects are just as prone to avoiding and tweaking open standards to suit themselves as anyone else. So I would be very wary of making too strong a case for linking open source to support for open standards. I have myself seen situations where managers have been forced to choose between an open source solution which did not interoperate with anything, and a closed source one which implemented open standards!"

Open standards

"There has been work on producing lists of standards and compliant products for government before, such as E-GIF," Wilson continues. "However, as with the options list, there is always this issue of context and fit: A product may support a standard, but how and why? Does it really matter if none of the other solutions in the organisation implement it anyway? What if it supports export but not import? Do you need to buy the 'enterprise edition' to get the full range of options? It's a multi-sided question that does not always lend itself well to making lists."

Here Wilson quotes Rob Abel, the CEO of IMS GLC, a consortium in the education space: "I think he summed it up well in a talk at the CETIS conference in 2011: 'Vendors know when clients are asking for standards compatibility in order to check off a box on an RFP. That is why we must include true, tested, guaranteed interoperability as a priority in our purchasing decisions, and why we must pressure our current support vendors to provide it as a condition of their continuing good business relations with us.' By 'vendor' here he means open source vendor and closed source vendor equally."

"Looking at the matter from the other direction, we also have the issue of patents and licenses for standards. For example, there is the current debate around the incompatibility between FRAND standards and open source, as well as the issue of patent encumbrance for video codecs, which is making supporting video more complicated than it needs to be. So in some cases, mandating standards can put in place additional barriers to adopting open source, and this is something policy-makers need to be aware of." Note that Wilson is also Assistant Director at CETIS (the JISC Centre For Educational Technology Interoperability Standards) so he has a stake in both open source and open standards.

Evaluation methods

To evaluate software that is not on a list of suggested or approved packages, various methods are available: more than one Open Source Maturity Model (OSMM), Qualification and Selection of Open Source software (QSOS) and the Open Business Readiness Rating (OpenBRR).

"Most of these are frameworks for evaluating a single solution or project," Wilson explains. "SSMM is more a framework around these for the process of selection narrowing. At different phases of the selection process you may then need to bring in QSOS or BRR or another methodology depending on how much time you have and how many candidate products are being considered at that point."

"For example, in an 'approximation' phase you may be listing a few hundred candidates, and so you would not perform a QSOS analysis on each one, but would instead use a much faster method to get down to a 'silver' list. At that point you could select an appropriate methodology for narrowing down to 'gold' candidates."

"Some frameworks work best for only open source solutions, others can work better across both closed and open source systems. And they all have different requirements in terms of the time it takes, the skills required, and so on. We tend to focus on using SSMM since it's a meta framework that is agnostic with regard to individual analysis tools. That means we can work with organisations that have chosen to work with any of the other methods at the product level."

Openness Rating

The Openness Rating is another tool developed by OSS Watch, in collaboration with open source expert Pia Waugh. "It is designed to guide evaluation of a project's structure with respect to the management of intellectual property, standards adoption, knowledge management, project management and market opportunities. Unlike earlier models designed to evaluate open source projects, this model can be applied to both open and closed source software products."

"The openness rating allows one to identify strong and weak points in a project's management structure with respect to enabling third party collaboration and reuse of outputs. This enables project managers to identify areas that may be unintentionally limiting collaboration opportunities. Similarly, the rating allows third parties to understand what barriers exist with respect to making local modifications to a third party's software outputs. By using this tool both parties can more effectively plan their allocation of resources in line with their needs."

"It is a set of metrics with a related question set that we use with projects to help identify any barriers to external contributions," Wilson elaborates. "The target audience is projects using an open development approach — typically incubated in R&D projects in an academic environment — that are looking to open development for future sustainability. The Openness Rating looks at a range of issues — legal, dissemination, tools and processes — to help identify where projects can remove barriers and improve access."

"We use this as part of our consultancy process with projects. JISC [the Joint Information Systems Committee — the UK's expert group on information and digital technologies for education and research] funds us to provide services to UK universities and colleges, so we can offer this for free depending only on availability. Typically we will conduct an investigation using the Openness Rating and develop a report for the project. Then we meet with the project team and discuss our findings. The project then has a set of specific actions they can take to improve their openness. Depending on the project we may then perform a follow-up consultation at a later date."

"The Openness Rating can also be used within the SSMM on a per-project basis to assess openness of a range of candidate projects. This is useful when the purpose of using SSMM is to select projects to engage and collaborate with rather than to just deploy and re-use software."

The open source specialist: a very pragmatic approach

"An approach wherein open source options are considered equally on the table is important if agencies are to make the best procurement choice, as they need to ensure they understand their options before committing a particular way. This list of 'Open Source Software Options for Government' along with references, case studies and what they are viable alternatives for, is a very pragmatic approach," Pia Waugh says. She is an open source expert currently involved in Open Government Policy and Projects, Australia. Previously, she worked with OSS Watch on the Openness Rating, looking at different aspects of "openness" in order to help people understand the practical implications of any software solution.

"It can also be useful to present software stacks," Waugh says, "because these are often a good fit to the use patterns identified by public agencies. But software stacks should not be seen as a complete replacement for their individual components."

"In this regard it is worth noting that if vendors do not respond to government tenders with open source options, then these can not be selected (for any work requiring tendering). So part of the challenge is how to also be sure that the responses to a tender represent an appropriate range of procurement options, including any valid open source options. In Australia, our open source procurement policy requires that tenderers demonstrate how they have considered open source, an interesting way to challenge the market into ensuring all options are on the table."

Technical review

The Australian policy says: 'For a covered procurement (over AU$80,000), agencies are required to include in their procurement plan that open source software will be considered equally alongside proprietary software. Agencies will be required to insert a statement into any Request for Tender that they will consider open source software equally alongside proprietary software.'

"The position of the Australian government concerning interoperability, open standards and open source is simple: We should review all options on their merit. The link between open source software and open standards is easily made in a lot of cases. However, it is important to not assume something open source is based on open standards, nor that a closed source solution is not based on open standards."

"So it is very important that part of the procurement process is a technical review (including functional testing) to ensure the interoperability of all products procured. Too often a vendor claims open standards but in practise the standard is not actually all that open or interoperable. Only through functional testing can an agency be confident in the claims made by a vendor, whether they are putting forward an open source, closed source or hybrid solution."

Useful extensions

"This list would naturally extend to health and education, both being largely government-centric," Waugh says. "This list would be great for public sector education. Perhaps rather than an all inclusive list, having some portfolio-based addenda to delve into verticals would be interesting for people in those sectors, and again help educate public servants in the business of government IT on options available to them."

"Furthermore, I think that open source methodologies are also of great value, in looking at how we develop software, share, collaborate and build upon the work of others rather than creating bespoke complex systems that become a millstone. Guidance and support about how to engage with and emulate open source software development would be useful to government."

"Another useful addition to the list would be tools for open government, such as open data tools (e.g. CKAN), data visualisation tools (I note R is already there, but others), social media tools, public engagement platforms, and collaborative tools such as collaborative document editing. It was great to see the geospatial tools in there, but open government stacks could be useful as well."

On the table

"However, even an extremely extensive list of options will not lead to actual change in procurement processes unless the market responds with open source options on the table," Waugh warns.

"Lists of viable open source software have been made for many years in jurisdictions around the world. However, instigating actual change in procurement decisions requires education, an engaged IT sector, good policies that ensure all cards are on the table, and case studies that demonstrate success. Open source provides many options for the public service but it is not a panacea. Open source is not always the right choice, but it is important that IT decision-makers in government have the skills, knowledge and interest in ensuring all options are considered in procurement for the public service."

Open software approach

According to Waugh, the evaluation of open source packages that are not on any list is mostly a matter of research. "You should be looking at the commercial support (both locally and internationally), case studies, and how active the developer community is. Basically, it's the same approach you should already take with any type of software. In a way open source software is less of a procurement risk than proprietary software, because a company could close down, be bought out, or simply choose to not support the software any more, and you have nowhere to go. At least with an open source solution other vendors could pick up the slack, and there is some competition at a services and support level leading to a reduced likelihood of service/support lock-in."

She agrees with Wilson that software packages should not be evaluated on their own: "Ideally, software needs to be tested against the business need, taking into consideration interoperability with other systems, future sustainability of the product, exit costs and more. In my opinion, rather than open source software evaluations, it is better to have solution evaluations that equally evaluate open source and closed source options in a consistent manner."

"I believe it is in engaging openly and publicly on such questions that government will get the best answers and be able to tap into broader expertise. It is important that we do not just look at open source as an opportunity for technological improvements in government, but as an opportunity to do things better. The default approach of open source is to look at what has been done before (re-use), to have an open roadmap, to collaborate, to have public discussions about strategy and direction, and to make decisions based on a technocratic process. These are all useful lessons that can be integrated into how the public service operates, both in IT and beyond."

The IT consultant: a licence comparison

"The list of options is a good starting point, although some software packages are missing," says Emidio Stani. He is an IT consultant at Unisys Belgium, specialised in open source. "It could use more software in bug tracking, wiki, CMS, code repository, programming IDE, and online surveys. Often you need to collect requirements when you cannot reach your client or people to be interviewed. Furthermore, an online survey can give interviewees the flexibility to answer the questions at their own leisure."

"But for a public agency it is more than enough. Just updating the list from time to time, e.g. every year, should be sufficient. And I would not add packages for administrators that are too low-level. A public agency usually has its own internal IT department for application setup, but it needs consultancy to use or create software for its specific needs."

"The software on this list is generally mature enough for professional and operational deployment. But maturity is also a matter of flexibility to changes. Many times applications require customisation to be adapted to a new environment, and thanks to the fact that they are released as open source they can easily be adapted."

In addition to the inclusion of use patterns, Stani thinks the list should at least have a licence comparison: "This is the first problem a public agency faces. I know it is in the TCO document, but I think an additional column should be added to the table."

Preconditions

"For applications not on this list, people should first refer to Joinup, OSAlternatives, or the software comparisons on Wikipedia," Stani says.

"But often software is not just taken as it is. It must be integrated in a pre-existing environment, with a database, by a developer. So in the end the choice depends on the internal needs. In practice you have to measure the TCO for yourself. There are other maturity models but in the end it is a personal choice, based on the experience of the people working inside."

"I worked with the European Space Agency (ESA), for example, using a maturity model to determine which package could be useful to them for a particular project. In that case preconditions came from requirements related to security and flexibility in integration, considering that the system should last ten years at least."

"Public agencies should be better informed about maturity models, but often they rely on contractors' experience for their decisions. The problem with that is if we want two packages to be used together, a decision from one contractor can have consequences with other contractors, which in turn can increase the cost to the agency. Therefore a public agency needs an internal central authority to make some decisions before starting a public procurement."

"This authority should ask question like these: Is it just one package or are there several packages to be integrated (which is the case most of the time)? If I modify and release the software as a service, am I obliged to release the source code? What are the security constraints or scalability requirements? How many people should be involved in managing the software?"

"Government can also accept feedback from companies to enlarge their choices. Interoperability is created not only through these kinds lists but also by intervening in public procurement policies, as recently happened in Italy where the first choice should now be an open source package rather than a proprietary one."

Risk evaluation

"Independently of whether a software package is open source or closed source, procuring and deploying software is always a risk," Stani says. "Lists of options and maturity models help to mitigate this risk. A list can definitely provide a starting point when making decisions, since it is very useful for a public agency to know why another agency preferred one package over another. The ability to fork open source software can add more confusion at the beginning, but in the end having a choice is the strong point."

Stani, however, does not see any value in the creation and maintenance of a list of open source software options on a European level. "There should be generic guidance or criteria for member states to help them determine their own options lists. Then the lists themselves can be different, allowing governments to apply national legislation. Still, comparison of lists can help determine similar requirements, allowing for re-use, while having different options can help to assess a decision."

"But on a European level the added value of Joinup is vital. Creating a community around open source software useful to public administrations helps to spread the knowledge, so a public agency will not feel alone when taking certain decisions. A community also gives more value than a simple list because although a package may be mature enough, it might happen that the community is moving towards other technologies which of course you need to take into account when evaluating risks."

Germany: a certified open source stack

In Germany, the Open Source Integration Initiative (in German; OSII) brings together a range of open source software applications for use by businesses. It's an initiative by MFG Baden-Württemberg — Innovation Agency for ICT and Media — and the Open Source Business Alliance (OSB Alliance), aiming to improve regional innovation and competitiveness by supporting entrepreneurship in small and medium-sized companies, and connecting them with application-oriented research and public funding programmes. "We aim to create a low-cost modular solution — a software stack — that meets the needs of many different operating processes," says Timo Mustonen, expert in open source innovation ecosystems at MFG.

"Together with its partners the OSII covers the full spectrum of IT solutions: from groupware, CRM (Customer Relationship Management), ERP (Enterprise Resource Planning), DMS (Document Management Systems), Business Intelligence (BI), and Identity and Access Management (IAM), via middleware (Enterprise Service Busses, ESBs) and the Linux operating system, to backup and archiving tools. The OSII works to ensure the smooth connection of all components in the software stack, creating a complete solution for corporate users."

Open source alternatives

"We are familiar with the UK government's list of open source options," Mustonen says, "and we are happy that some members of the OSB Alliance [Open Source Business Alliance, in German; formerly Lisog and the LIVE association] are also on the list. It is good to see an official document that gives alternatives to the proprietary solutions and improves discussion and competition. This is something the OSII aims to achieve as well. It aims to be a source of both information and solutions to the needs of our customers."

"Some of the solutions mentioned are market leaders on open source software. Companies like Zarafa [a Dutch company providing an open source alternative to Microsoft Exchange Server], Talend [specialized in data integration], Jaspersoft [providing the open source Java reporting tool JasperReports], and SuSE Linux [now part of the Attachmate Group] are well respected and also members of the OSB Alliance. Most of the suggested options are already well-established and found successful, working and capable. For example, Moodle [Modular Object-Oriented Dynamic Learning Environment, an open source e-learning platform] which is used widely across Europe."

"The options list does a good job in giving concrete examples and recommendations in alternatives. I believe it was not intended as an exhaustive list on the pros and cons of individual packages, or a list of all available options. Such a list would be long and information-heavy. Too much information, in my opinion, can create a decision scare that keeps people in the familiar old solutions they have and be counter-productive to exploring and deploying alternatives."

An open solution stack

According to Sven Meintel, the network manager of OSII and open source expert at MFG, any company can join OSII if they want to: "The aim of OSII is to be a fully open solution stack. The only requirement is that the products offered have to be open source." So even traditional suppliers and system integrators are welcome. "We already cooperate with some of them. OSII is an initiative of MFG and the OSB Alliance, that works closely with the latter, where, for example, IBM is a member."

While the UK government's list of open source options is mostly based on knowledge commonly known to open source specialists, and offers suggestions for alternatives to proprietary software, the OSII stack takes a different approach. It offers a best-of-breed stack where the interoperability of the various packages is tested and guaranteed. "Our two partners, the Institut für Informationssysteme der Hochschule Hof (iisys) — a centre of competence for computer science — and fortiss (in German) — an institute for software engineering — test the components of the partners for interoperability, consistence, and other markers defined by the OSII. If the software component passes the test it gets a certificate."

According to Mustonen, testing and certifying for interoperability adds important value to a set of software packages. "If a stack has its interoperability in order, it can provide great benefit over individual components. A stack also lowers the barrier for adoption, since it makes open source software easier to take up, without having to spend resources in finding individual tools in a still fragmented environment."

International level

For the evaluation of the maturity and the deployment of open source packages not on any list or in any stack, Meintel sees no immediate solution. "But for the German-speaking world, you can get help from the OSB Alliance. They can provide you with answers, connect you to partners, and assist in everything concerning open source."

At the same time, lifting the OSII stack to an international level is certainly an option: "The German-speaking area is just the beginning. When we have a well working system — tested, certified and flexible — it is easy to implement new partners. And going international is definitely a possibility in the OSII future."

Conclusions

A list of open source software options can definitely play a role in the design of new IT solutions, to suggest opportunities for IT service or solution refreshes, and to challenge a proposed solution that does not use open source technology — on its own or as part of a broader software selection methodology and maturity model. It can help to create a level playing field for open source and proprietary software providers competing for government IT contracts, giving procurers the information they need to fairly evaluate all the options. It can be used in the demand organisation to gain familiarity with open source alternatives and to challenge IT suppliers. It allows public agencies to take control over decisions in technology that are now taken by large IT companies, creating freedom of choice, and shifting market power to the demand side. It can be used to help public IT managers overcome their fears, since using open source software instead of proprietary products is still perceived as a risk. Training of IT managers and procurement staff plays an important role here too, allowing them to make their own risk assessments and TCO calculations, and so instigating actual change in procurement decisions. And most importantly in relationship to tenders, open source alternatives have to be on the table first before they can even be considered.

However, the options list should be used with care. The best solution depends on the specific use and context, so software should be evaluated on a wide range of characteristics, and whether it is closed source or open source is just one of these. The list could be part of a broader software selection and evaluation methodology, depending on the stage of the process. Since there are many other open source packages available, it should be used as a starting point only, not as a definitive set of options, that could create barriers to both uptake of solutions and innovation. So the options list should not be prescriptive or definitive.

Other software packages should be researched, looking at the commercial support (both locally and internationally), case studies, and how active the developer community is. Software — whether open source or closed source — needs to be tested against business needs, taking into consideration interoperability with other systems, future sustainability of the product, exit costs and more.

The options list should be updated at least once a year. It should be used together with other resources like Joinup and other repositories, OSAlternatives, and the software comparisons at Wikipedia.

The relationship between interoperability, open standards and open source is easily made but not always true, so as part of the procurement process a technical review is required to ensure the interoperability of all products.

Useful extensions that might be added in future releases of the UK list include — besides the inclusions of more packages — a search engine and an interactive web interface, packages for verticals like healthcare and education, a catalogue of design patterns, licence information, more information on open source methodologies — how we develop software, share, collaborate and build on the work of others rather than creating monolithic systems that become a millstone — and guidance on how to engage with and emulate open source software development.

Since the options list consists of generic packages, and open source software can relatively easily be adapted to national policies and regulations, it could be elevated to a European level, allowing other countries to use it in a similar way.

In Germany, OSII brings together a range of open source software applications, guaranteed and certified to work together. It aims to create a complete, open solution stack, covering the full spectrum of IT applications. OSII takes a best-of-breed approach where the interoperability of the various packages is tested and guaranteed. A stack like this can provide great benefit over individual components, lowering the barrier for adoption of open source software. Lifting the OSII stack to an international level is certainly an option.