Friday 22 October 2010

EU Guidelines for Public Administrations purchasing software

The European Union has published excellent, very practical guidelines to support government agencies purchase software. While it is specifically targeted at purchasing Open Source Software, by its own admission, most of the discussion is valid for purchasing Proprietary Software too.
The key message that it describes in business terms, is the importance of using Open Standards in order to adhere to EU purchasing criteria of fair competition, transparency, and long term value for money.
The full guide is available here:

Below are some of the highlights I picked out as I was reading it:

Government Business Drivers
Public sector consumers of software have an obligation to support interoperability, transparency and flexibility, as well as economical use of public funds. When it comes to public procurement, the principles applied to the public sector require them to support (and certainly not to harm) competition through their procurement practices.
Pro-Proprietary discrimination
Studies have shown that in practice, much software procurement discriminates between individual vendors, typically in favour of specific proprietary software companies.

E.g. OpenForum Europe, 2008. "OFE Monitoring Report: Discrimination in Public Procurement Procedures for Computer Software in the EU Member States", December. Ghosh, R. A. 2005. "An Economic Basis for Open Standards". FLOSSPOLS project, European Commission.

Proportion of Software Spent
While precise figures for the European public sector are not available, it is worth noting that the share of proprietary packaged software in European software spending is only 19%. Much more is spent on custom built software (52%) and internal software development (29%).
European Commission DG Enterprise, 2006, Study on the Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU, pp124 (Table 24). Available online at

Defining Standards
Note that compatibility with previously purchased IT solutions may seem like a very valid technical requirement, but can also be a way of perpetuating the consequences of previous purchasing decisions, perpetuating vendor lock-in and preventing an unbiased procurement based on real organisational needs. Requirements for compatibility with open standards and no proprietary elements, i.e. full compatibility across multiple vendors and producers, increases the freedom of future procurement choices.
Funding drivers for Government
Freed from the obligation of the short term financial cycles of the private sector, public organisations are also obliged to maximise costs effectiveness over the very long term. However, with limited, short-term budget cycles, they need to find a good balance between limiting the initial investments and limiting the overall, long term cost.
Exist Costs
The exit cost is also an important consideration: the cost incurred in migrating to another IT system, which should properly be accounted for as a cost not of the new system being migrated to, but the old system being migrated from. After all, if the old system were based on open standards, migration would not be as expensive, thus the cost of migration is imposed by the current, old system.
Software is used to create documents, databases and customised applications that, in the public sector, have a life-time that may be well beyond the originally announced life-time of the procurement procedure for the software. If the software originally purchased makes it difficult to use the documents, databanks and customised applications with similar software from other producers, then there is a high cost in terms of changing from the original software to another software - the exit cost.
Buying new software because it is compatible with previously purchased software may seem to save on migration and training costs. But when this software is proprietary, and is not fully based on protocols and standards that are fully and freely supported by other independent vendors, exit costs and associated costs may greatly increase over the long term. The agency's dependence on the proprietary vendor is increased. Thus the apparent short term benefit of compatibility is much reduced when considered over the longer term.
Total Cost of Ownership Studies

Total Costs of Ownership (TCO) is a term often cited in relation to software purchases. However, there are several different methodologies, and few include all the long-term costs involved in software purchases, such as the costs of required regular upgrades, or the exit cost of Guideline on Public Procurement of Open Source Software P. 31 migrating to another software. It is therefore difficult to use TCO studies, or even compare them.
Furthermore, such studies rarely evaluate anything other than quantifiable costs; the benefits of flexibility, independence and transparency while essential to a public organisation, may be qualitative and hard to quantify. Thus, it is advisable to analyse costs and benefits for the needs of the public organisation concerned, over the long term, rather than relying on TCO studies.
Open Source Quality Metrics
A number of EU funded research projects are examining open source quality metrics, such as QUALOSS and SQO-OSS (;
Lowering Company Financial Viability for Open Source
The main justification for financial sustainability criteria for software is to ensure that the supplier will be able to provide support as long as the software is being used.
With open source, the availability of the source code assures interoperability, and there is no dependence on the original supplier. If the original supplier goes out of business, the software can still be maintained by others; if others are not maintaining the software, the public agency can hire a third party maintainer. This increased sustainability of open source is justification for lowering the financial sustainability requirements, or lowering their weight in the selection process for tenders for open source software.
Valuing Open Source engagement in selection criteria
Public agencies can also provide indirect support for the development community, by asking tenderers for open source software or services to demonstrate their level of contribution to the appropriate developer community - as part of the selection process, and/or as part of the execution of the contract. In any case, this may be a useful way of determining level of knowledge of the open source software and its community available with the tenderer.

1 comment:

Cameron Shorter said...

The website for the referenced EU Guidelines is down today - you can find a cached version here