Offerman Consulting
spacer Zone

Issues in open source procurement in the European public sector

Author: Adrian Offerman

Part two: policies

Open source is a natural way to implement open standards and attain interoperability. Despite the procurement policies currently in place, however, most governments have a hard time taking in this new model.

As a consequence, governments are suffering from high or even unsustainable IT costs. Large parts of their budgets are exported instead of being invested in regional companies and jobs. And public agencies are missing out on local talent and innovations. Recent research shows that the CSS-only market we are just leaving behind delivers lower welfare than a mixed market. So there is every reason to identify and address the current issues, to improve value for taxpayers' money.

This article is a follow-up to a previous story in which we presented the issues in open source procurement in the public sector, as revealed through interviews with representatives of the open source suppliers in the four largest European countries.

Here we present the responses from three of the governments concerned — Spain, the UK and France — and discuss their policies. Despite being asked for input several times over recent months, the German government was not able to respond to our requests.

The section on the situation in Spain is based on two interviews with Cenatic, a public foundation aiming to increase knowledge and awareness of open source technology, policies, and methodologies. The part on the UK is based on two interviews with open source specialists at the British Cabinet Office. The third part gives a detailed overview of the new open source policy in France.

But we start with an overview of the problems as they were brought forward by the open source representatives of Spain, Germany, the UK and France. Their full stories and a breakdown by country can be found in part one of this diptych.

Issues as presented by open source representatives

Open source companies

  • open source suppliers are mostly small companies, with a few medium-sized firms (SMEs);
  • small open source companies often lack capabilities in project management, professional consulting and support, and cannot provide the continuity and trustworthiness larger companies can;
  • the open source market is still very fragmented, hindering suppliers who need to provide highly integrated solutions.

System integrators

  • large system integrators rely on these small open source specialists to provide expertise and maintain relationships with the community, since they do not have these capabilities themselves.

Public agencies

  • public agencies in most countries lack the expertise, the experience, the will, and sometimes the courage to purchase open source;
  • the public sector in most countries is way behind the private sector.

Public tenders

  • public tenders are not (directly) accessible to open source suppliers;
  • public tender processes in most countries are too formal for smaller companies;
  • open source suppliers can seldom carry this administrative and financial burden;
  • open source companies often lack the legal expertise to participate in public tenders;
  • some countries have policies specifically targeting SMEs, others don't.

Tender malpractice

  • although the right policies to create a level playing field for public tenders are already in place in every European country, their implementation in most countries is deficient;
  • public agencies in some countries often explicitly ask for specific commercial products and companies, against public tender law;
  • public tenders in some countries are only accessible to a small coterie of proprietary suppliers who always win the tenders;
  • procurement lists are another way to limit access for open source suppliers;
  • in some countries open source is merely used to reduce the price of proprietary software;
  • open source companies can be invited to tender just for statistics or show;
  • access to public tenders for SMEs can be frustrated in implicit ways too, using all sorts of unnecessary and irrelevant requirements, policies, and references, even for very small tenders.

Consequences for the open source supplier market

  • open source suppliers in most countries gain no access to their public home market, and get no support or encouragement from their governments;
  • all this has resulted in very low demand for open source in the public sectors of some countries;
  • as a result, open source suppliers and advocates in some countries have turned their backs on the public sector;
  • although the supplier market, mostly built on a services-only model, is thought be a viable business, open source companies in most countries are languishing;
  • their small size and limited resources prevent open source companies and advocates from developing, growing and maturing their own markets.

Consequences for the public sector

  • this lack of competition can make the public IT market supremely profitable for a handful of large companies;
  • in some countries IT spending is unusually high, and no longer sustainable;
  • by excluding open source suppliers from participating, public agencies are missing out on local talent and innovations;
  • open source suppliers who are unable to participate in their home markets may be forced to look elsewhere, or even relocate abroad;
  • by keeping the public market closed to local suppliers, large parts of IT budgets are exported instead of being invested in regional industry and employment.

Other

  • cloud-based infrastructures carry the risk of a new lock-in.

Conclusion

It is clear that there is still a lot of work to be done in the public open source market. Although the situation in France appears to be heading in the right direction, open source markets in other countries are still deficient. But the good news is that the infrastructure is now in place. Tender laws and policies are reported to be adequate. Implementation, however, still needs a lot of effort and a change in attitude on the public side. The private sector can serve as an example here.

Open source companies, in turn, need to grow and mature before they can seriously and independently participate in public tenders. Until then, traditional integrators are bridging the gap between the needs of large public organisations and the limited capabilities of the mostly smaller open source suppliers. And there is good news here too: open source suppliers in most countries appear to be well organized and well represented, they are organising themselves into alliances and consortia, and they are still growing and maturing.

Spain: centralised policies

The Spanish open source strategy is based on legislation for re-use, sharing, and collaboration in IT systems between public administrations building on interoperability. Following European recommendations, since 2007 Spain has issued laws binding public administrations to acquire software based on open standards, to look for re-usable solutions before buying licenses or taking up new developments, and to facilitate code sharing between public administrations, said a Cenatic spokesman previously.

Cenatic (National Competency Centre for the Application of Open Source Technologies, in Spanish) is a public foundation aiming to increase knowledge and awareness of open source technology, policies, and methodologies. These strategic lines established by the Spanish central government have been embraced by several autonomous communities providing specific methods of for re-use, sharing, and collaboration in their regions. Special interest has been raised by the Basque Country decree on openness and re-use, and the Andalusian public administration repositories.

Spain has also developed an application repository and forge (in Spanish) for free re-use between public administrations ruled by the Technology Transfer Centre of the Department of Public Administration. And we have various initiatives to facilitate the procurement of open source software by public administrations, especially for municipalities where a significant lack of technical and legal knowledge gives them difficulties in formulating proper tenders. The ALIAL Guide, for example, was developed by the Spanish Federation of FLOSS Companies. It contains a list of certified companies providing open source products and services. The ALIAL Guide simplifies procurements by providing models for documents and specifications. Also, in Januari 2012, Cenatic launched the Open Source Legal Community, a legal community supporting the development, installation, and adoption of open source software in the private and public sector in Spain, and the AAPP Forum, a community of practice for sharing experiences and best practices on the migration to open source software in government.

Infrastructural level

Manuel Velardo, the CEO of Cenatic, makes a clear distinction between the public and the private buyers' market. Large corporations are basically consumers of IT and related services and have low expertise and confidence in this whole thing called open source. And if they do, it's limited to the infrastructural level. And that's also true for the vast majority of the open source sector, where SMEs dominate, and focus on this specific layer with their Linux-oriented products. Most of the corporations, however, don't even really care about infrastructure: today it is this, and tomorrow it will be in the cloud or somewhere else.

So on a business application level, there is a lot of on-premise or packaged ('commercial') software and virtually zero open source software. In fact, it is the huge companies that produce the vast majority of software in Spain, in cooperation with the private IT sector. We are only now entering the next phase, where they give the code back to the market, publish it under an open source license, and maintain the software through an existing community or create a new one. We have seen movements in this direction in the banking and telecom industry, for example. Small companies, however, have a lot of troubles and obstacles to enter the supply chain of those huge companies. That is something we have to work on, to shine a light on these small open source companies and demonstrate their value to potential clients.

All this is completely different in the public sector, Velardo continues, where we have policies supporting open source, enabling local companies to deliver their solutions. There is more knowledge in the public sector. Recently, the Ministry of the Treasury and Public Administration Services has made available a list of services and all are in line with open source. So we are relying on open source, and sometimes we rely on small IT companies too.

Furthermore, we are more keen on publishing our software as open source than companies are. Public agencies who maintain their software in a community, or participate in one or create one, are lowering the cost of maintenance and fostering re-use and collaboration. There are a lot of examples available at Forge Fusion (all in Spanish): OpenDNIe, Urbanismo en Red, and XBRL APIs. And the list is growing every month.

Young CIO

According to Velardo, it is important to have a central CIO (Chief Information Officer) for the public administration, in order to define effective policies. Young CIOs are more used to open source than older ones. And you need an explicit policy to obtain the benefits from open source software. Earlier it was almost impossible for us to make open source policies, because every site had its own CIO and he could basically do whatever he wanted. But since this summer a single CIO has been responsible for Extremadura, Catalonia, Valencia, and Andalusia. This guy is about forty years old, maybe even younger, and he definitely has more trust than his predecessors in open source software at the infrastructure level and on the desktop side. So now almost all regional public administrations have started to centralize their policies on digital infrastructure.

Cenatic has been involved in 46 projects published as open source, and this year we have been working with four local governments to develop open source policies. They are starting to believe that the maintenance costs of open source will be lower. Velardo is talking about huge cost reductions. There are administrations that are saving 65 percent on maintenance and software development. Furthermore, every euro we invest in the software community returns three euros to the local IT sector.

No value-add

At the same time, Velardo warns for system integrators who do not develop software themselves. These companies should participate in the communities that maintain the software they are selling as a service. Now they provide only services. They just pick the software from the internet and sell it to their clients. But they are not engaging with the community, so if the developers decide to change the roadmap or whatever, the client is lost because there is no way to influence and interact with the programmers, and in the end you are stuck (again) in a software solution.

So the integrators do not add any value to the package, and a client has no way to steer the further development. That is more or less how the IT industry currently works: all is based on services and not on in-house products. But there are companies like OpenBravo, Zylk and Zentyal, that take software from a project, enhance it, create innovation, and participate or create new ecosystems. That is the power of free software: work with the community.

What is needed is for small open source companies to grow into professional organisations — but right now they are having a very hard time. They are small companies, often employing only three to five people exceptionally skilled on the IT side. They have to foster marketing and cooperation with the community, to take real advantage of their business model and overcome their troubles with large-budget projects.

Two-tier market

So what we have right now is a two-tier market, Velardo continues. Large buyers always rely on big vendors, and these big vendors require services from small companies that are not worth a lot of money. So in the end the client gets a really nice solution made by a very small company, but most of the money goes to the big integrators, because large buyers don't know how to deal with or even know small companies. So even though public agencies are asking them, and all the procedures are in place, these small open source suppliers are not able to actually enter this market themselves.

Cenatic cannot solve the problem of public agencies deliberately violating European tender law by asking for specific product names — usually proprietary ones — in their calls for tender. That is not our mandate. We have no lawyers or prosecutors; we are not the tender police. We are a technical body in the public administration that advices them on how to purchase open source, how to liberate their software, and how to create communities for software sustainability. There are only thirteen people in our office. We cannot be present in every single IT department, in every single part of the administration. We can only insist on the deployment of open source as a way to implement technological interoperability and sustainability.

But tenders should be more open. Sometimes I see names of proprietary packages, and sometimes I see open source names. It is difficult to prevent that, since there are no prosecutions. And the European Commission has no power to check on this. It would be almost impossible anyway, because you can ask for a specific product if you can justify it.

Associated suppliers

One way for open source companies to overcome their limitations, is to get organized. What we do see is that certain open source suppliers are starting to associate, Velardo says, and in a very orderly way they row together towards a tender. There are only a few initiatives today, but some of these have really worked out.

Of course it requires a lot of coordination between all these small companies. That is important not only to the companies themselves, but especially to the clients, because they cannot manage twenty one-man bands. We have seen great initiatives in regional associations in the Basque Country, in Galicia, and in Catalonia. They are doing a great job in their coordination because they invest money in management. They are paying a manager to talk about trends and best practices, to stimulate political discussion, and so on. That is great; for now they can delegate this terrible and complex thing to a guy who really knows how to do it. And they are actually winning some tenders, and selling a lot abroad, looking for new markets.

Standstill

Today we have to be content with a centralized policy, Velardo concludes, as it has taken a long time to get this far. This will make it easier for us to try and influence the big decisions and to put into place good practices. Now we can enter the difficult stage of getting rid of all the ancient and informal ICT, the contractors and so on.

But because of the financial crisis, at this moment it's very hard to contract for new development projects or new deployments. What they will do is mainly maintenance, and I'm afraid they will call the same providers they always have. Due to the crisis, innovation in government IT has come to a standstill. Certain regional administrations are limiting all expenses just to maintaining the software they already have. That way, of course, you are saving money in the short term, but missing out on innovation and the lower costs of open source software in the long term. Furthermore, open source allows you to innovate at very low entry cost, Velardo points out.

Migrations and rationalisations of the software landscape, on the other hand, might cost a lot of money. And the problem is that you don't have this kind of money in this year's or even next year's budget. The public sector is not able to have an IT budget for four years. But the benefits of open source may not be visible in the first year, may be in the second, and will definitely be in the third to fifth. But no-one can tell what politics will look like next year.

Summary

  • the Spanish open source policy is based on interoperability;
  • legislation is levering on re-use, sharing, and collaboration;
  • they facilitated on both a national and a regional level by Cenatic, a public foundation aiming to increase knowledge and awareness of open source technology, policies, and methodologies;
  • to large corporations, open source is not an option on a business application level, due to an absolute lack of knowledge about projects, companies and technologies at the suppliers' side; yet these large companies are important software suppliers to the government;
  • centralisation of digital infrastructure policies is an important enabler for open source, getting rid of traditional and informal IT;
  • open source generates huge reductions in maintenance and development costs; furthermore, every euro invested in the software community returns three euros to the local IT sector;
  • system integrators not developing software, not engaging with the community, and only providing services, do not add any value to the package; furthermore, the client has no way to influence and interact with the programmers, and no entrance to steer the further development;
  • in the current, two-tier market, large buyers rely on large suppliers, at their turn relying on small open source specialist companies not being able to compete in this market themselves; although the software solution is made by a very small company, most of the money goes to the big vendors;
  • tenders should be more open, to prevent the appearance of specific package names in the requirements;
  • open source suppliers are starting to associate to participate in tenders, sometimes even investing in management;
  • currently, the crisis makes it very hard to contract for new development projects or new deployments, causing innovation in government IT to come to a standstill; public agencies focussing on maintaining current software are saving money in the short term, but missing out on innovation and the lower costs of open source software in the long term;
  • yearly budgets are limiting large migrations and rationalisations.

The UK: a work in progress

After making the use of open standards mandatory through its public procurement policy, the British Cabinet Office now requires government departments and agencies to actively consider open source solutions in making procurement decisions. Open source software should be given fair and equal consideration as part of a procurement exercise, Niki Barrows, member of the Strategy & Architecture Team at the Office of the CIO of the Home Office, said previously. But procurement decisions will continue to be made on the basis of best value for money.

The current government policy states that Procurement decisions will be made on the basis on the best value for money solution to the business requirement, taking account of total lifetime cost of ownership of the solution, including exit and transition costs, after ensuring that solutions fulfil minimum and essential capability, security, scalability, transferability, support and manageability requirements. However, the Total Cost of Ownership model which was developed to help with a fair evaluation of a wider set of costs than might currently be considered is poor.

Better for Less

The British strategy is the outcome of a business plan published in November 2010, making a commitment to improve the rules around designing and running ICT projects and services. The first steps were taken by Liam Maxwell, back then as a local government representative responsible for IT policy for the towns of Windsor and Maidenhead. As the Director of ICT Futures he is now advising at the Efficiency and Reform Group (ERG) within the Cabinet Office. And recently he was appointed deputy government CIO, next to government CIO Andy Nelson.

As a member of the now defunct conservative research group Network for the Post-Bureaucratic Age (nPBA) Maxwell made two key observations in the report 'Better for Less: How to make Government IT deliver savings'. First, IT is too expensive: At £21 billion the annual cost dwarfs some government departments. It is three times the amount we spend on the army, more than the Department for Transport. Putting the government IT cost into perspective: it is between one and two percent of the UK's GDP, and almost ten percent of it is spent on the procurement process.

Second, the quality of IT is poor. And that's also true of the procurement process: it is inefficient and badly designed, resulting in excessive spending. Furthermore, small companies cannot deliver their dynamic and innovative solutions to government. According to this report, a strategic change steering away from this unsustainable situation could save 40 percent — £8 billion a year — while at the same time providing better services.

The keyword in this transition is openness: of government data, of standards, of software, of platforms, and of markets. Standards should be managed centrally yet applied locally. Citizens should own their data, while government is responsible for its security and use. And government should be in control of its programs, with outcomes being more important than targets.

UK Government ICT Strategy

The road map for open source sketched in the 'Better for Less' report starts with a transition to ODF (OpenDocument Format), followed by a desktop fully based on open source software. Microsoft and Oracle frameworks should be replaced by central mail and office productivity services, saying goodbye to these tier one suppliers selling monolithic software under monolithic contracts. Where necessary, the government should develop its own software, for example for education. Identity and personal data management should be organized centrally but be controlled by the citizens. Politicians and policy makers should become tech-savvy, and governments should build their own in-house expertise, so they know what's out there and can communicate on an equal footing with the suppliers (demand organization). Open source software should enable the re-use of code, applications and business functions across government.

In March 2011 a detailed Government ICT Strategy (in PDF format) was published, containing three items specifically on open source:

  • Government will create a level playing field for open source software.
  • Where appropriate, government will procure open source solutions.
  • Government will remove barriers to allow SMEs, the voluntary and community sector, and social enterprise organizations to participate in the government ICT marketplace.

and two associated actions:

  • To create a level playing field for the use of innovative ICT solutions, the government will publish a toolkit for procurers on best practice for evaluating the use of open source solutions.
  • To assist with the deployment of agile solutions using open source technology, the government will establish an Open Source Implementation Group, a System Integrator Forum and an Open Source Advisory Panel. These will aim to educate, promote and facilitate the technical and cultural change needed to increase the use of open source across government.

Strategic Implementation Plan

In October 2011, the ICT Strategy was accompanied by a Strategic Implementation Plan focused on standardising government ICT: In the past, government departments worked to their own requirements and often procured expensive bespoke ICT systems and solutions to meet them. As a result, departments have been tied in to inflexible and costly ICT solutions which together have created a fragmented ICT estate that impedes the efficiencies created by sharing and re-use. It also prevents government from offering joined-up, modern, digitally-based public services that are suited to local requirements. The approach set out in this plan ensures that departments will now work in a collegiate way, underpinned by rigorous controls and mandates.

Although we focus on the common infrastructure as a way of significantly reducing costs, implementation will be driven through the centre, as a series of smaller, local ICT elements, rather than 'big bang' programmes that often fail to deliver the value required.

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. 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.

Governance structure

According to the plan, a governance structure has been established which includes three key bodies to lead and coordinate activities to remove the barriers to the usage of open source solutions:

  • a cross-government Open Source Implementation Group to ensure departments are evaluating open source solutions;
  • a System Integrator Forum to ensure their compliance with open source policy and identify barriers to its uptake;
  • an online Government Open Solutions Forum (referred to in the ICT Strategy as Open Source Advisory Panel) to provide technical, legal and business process advice on open source solutions.

The key milestones and completion dates are:

October 2011 produce procurement toolkit to assist departments in the evaluation and adoption of open source solutions
October 2011 produce initial Total Cost of Ownership model and baseline
March 2012 capture lessons learned from non compliance with open source strategy
March 2012 100% of departments will have access to the toolkit
March 2012 introduction of maturity model to encourage uptake and embedding, followed by annual review of departments' maturity on open source
March 2013 100% of all department software procurement activity includes an open source option analysis

And the top three risks:

risk mitigating action
failing to get the departments to change current buying and development practice — busting the OSS myths guidance, measurement, assurance and compliance
failing to change System Integrator (SI) behaviou identifying and addressing barriers via the SI Forum; explaining the benefits and possible win-win scenario
absence of collective app store / Asset and Services Knowledgebase identify key dependences and proactively manage across ICT Strategy

Open Source Procurement Kit

In October 2011 the Open Source Procurement Kit was published: a sextet of documents making it easier for SMEs selling open source solutions to compete for government contracts. In April 2012 the toolkit was updated and extended. The information in the toolkit aims to let people know that there are other solutions out there, said Barrows, and to give procurers the information they need to fairly evaluate all options.

A list containing dozens of open source software alternatives to proprietary applications has been published as part of the procurement kit. 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. The list was one of the documents updated in April 2012.

A cultural thing

Despite all these ambitions, policies and plans concerning open source, the UK has not been doing a good job with regard to the implementation of its open source strategy. We have had our policy on open source since 2004, says Tariq Rashid, who is responsible for Strategy & Change at the Cabinet Office. In that time, we haven't really done that well. We know this, because we look at the private sector, and we look at other countries. We have noticed that we have a lot less open source software in use than they do. France, Spain, Germany, but also countries outside Europe — the US, India and Brazil — they are all doing very interesting things.

Although the open source policy has been there for a long time, administrations have not been following it. The words sound nice in theory, but in practice it has proven to be very hard. So we had to find out why in real-world projects open source had been falling away as an option early in the IT cycle. That has revealed a number of issues which we are currently trying to address. Those include issues around security, for example, related to the open source development model, and the open source suppliers, which tend to be smaller. But there are commercial reasons as well. One is that the big companies that we outsource to have preferred not to use open source software.

We could keep on going producing strategy documents, Rashid says, but that is not going to solve the problem. It's cultural, on the work floor. In the UK government, IT buyers do not have the same kind of experience as those in other sectors.

So we have both a top-down and a bottom-up strategy. For example, we issued a short statement on security, that says that open source software as a category is no more or less secure than proprietary software. And we engage in real-world IT projects, trying to understand what stops open source software being given a fair evaluation, and intervene or support as appropriate.

Open source alternatives

The list of open source alternatives tries to address some other issues, Rashid continues. The IT staff at the departments were not familiar with open source: they did not know what it was, and they were unable to evaluate the suitability of particular open source technologies. That makes them unable to engage in the wider market and challenge an IT supplier offering potentially expensive solutions. So it's a problem in the demand organization that we take very seriously, but one that we are not able to solve quickly. The list of open source options is 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 whole 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 it. 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.

Two new approaches

Another problem that the UK government is working on is the tenders that are not accessible to open source suppliers. The new government has brought in two new approaches, Rashid explains. First, we want to use the mechanism of public transparency to make sure that we drive better procurement behaviour. So we want to, increasingly, publish publicly what we are doing. For example, we are now publishing contracts after they have been agreed. And we are thinking of extending the scope to much earlier in the requirements stage, so that we actually publish what our business problem is. By putting our requirements out there, we make sure that we widen opportunities for alternative suppliers and innovative solutions, and not just procure the solutions from suppliers we already had in mind.

The second thing is already in place. In central government our office has taken the power to require an additional check on IT spend at a certain treshold, which is roughly £5 million. What it means is that IT spend, even if it has been through departmental process and governance, has to receive final approval from the Cabinet Office. We ask questions like: Have they considered open source? Have they used open standards? Is it an open architecture? Have they used cloud services? Have they broken the programme into smaller pieces, where some of these can be undertaken by SMEs? And questions like: Have they undertaken an effective competition? Are the services disaggregated away from monolithic black box solutions? If we are not satisfied on such questions, we can push back and ask that the departments undertake further work. We would love to look at everything, but we don't have the resources for that. But for these projects above £5 million I think in a year we made savings of roughly £400 million.

This function of approving and rejecting large projects is executed by the spend control team, part of the deputy government CIO office, now run by Maxwell. This tactical function of expend control has proven to be very powerful, Rashid says, Where perhaps in the past, some have not concerned themselves with open standards and open source, the spend controls process means they are now having to understand what these are, and their potential business benefits.

Cases

Rashid admits that a substantial part of his work is to fight internal battles. It's a confrontational job sometimes, but it has to be done. There are now a few people in the right places. The challenge now is to change the dominant culture that is afraid of this new idea. So we ware devising actions to do that. We are also reducing contract length periods, challenging those longer than one or two years. We don't like large contracts: there is a presumption against any single contract over £100 million. We have to have more diversity, more competition.

Another action to change the culture is the promotion of good open source cases. If departments have successfully used innovative approaches and good value IT, we try to promote it. The next time someone wants to spend some money the old way, we can tell him there's a better way and that it's not theoretical: 'Here is an example, and it works: it's lighter and it's less expensive.' And we do have excellent examples of open source in government IT, from the Government Digital Service wide use of open source and agile development, to The National Archives use of open source data technologies, and the Home Office using better value infrastructure technologies.

At the same Rashid admits that they have not been very good at publicising case studies. We do need to do that more so we are aware of how much open source is in fact used in government, to dispel some of the uncertainty around it. It's sometimes difficult to find them and we need to solve this.

Negotiating position

In time Rashid expects to have a good over-all impression of where departments are with IT, and what they have in the development pipeline. We are requiring departments to inform us of their IT estate, what technology assets they have, what software, what services, and what they want to do in the near future. Such information is key if we want to re-use our own assets, but also key if we want to negotiate better prices and contracts. If we don't know what we have already paid for, not what we are using, or expect to use, we are not in the best negotiating position. A transparent forward view of what we expect to spend also helps new and smaller suppliers become potential bidders. We now publish such IT investment pipelines.

Getting started

Government IT managers willing to go open source but lacking the expertise and experience are welcome to come to Rashid's team for support. People can request any kind of help, and they do. Sometimes it's a small technical question, and sometimes we get big questions, to get involved in a large project or programme. We try to help, and if we can't we find additional and sometimes external expertise. We have, for example, been involved in two large projects. On one we significantly reduced IT spending. That took six months of involved work.

It's very important that IT managers know that there is a contact point they can go to, Rashid says. In addition to the open source support team, largely based at the Home Office, the Cabinet Office team is also expanding it's engagement with departments so that we can support projects at a much earlier stage, where we are more likely to be effective.

Risk management

Rashid agrees that this is very much like it was over a decade ago in the commercial sector, where IT managers were afraid that they would lose their jobs if they deployed open source. They didn't come from that world, they had no experience, and no way to evaluate open source software. So to them it was a risk. We are still in that position. Too many government IT professionals don't have experience and expertise in open source. And if they do, their IT managers and senior leaders don't understand it. So considering open source is perceived as a personally risky thing to do. What we have to do is promote the message that what they are doing is very much aligned to the ICT strategy, and therefore they have permission and authorization to explore open source. This problem is not going to be resolved overnight, but we are finding that people feel more empowered, because the government's senior IT leadership is confirming that they are doing the right thing.

A key issue is outsourcing technology or solution design risk, which means others make technology design choices for us. We don't then have a say in which kinds of technology, open source or otherwise, are selected. We are trying to address that. The theory says that we are outsourcing risk. The reality is that we are not. The impact of the risk is always with us; the cost always comes back to us.

There is a correlation between those who do not outsource their IT, making their own IT decisions, and the value for money they get from their IT. I think we need to do some work in quantifying that, to confirm our belief that if you are an intelligent customer you can make better IT decisions to deliver better value for money.

The CIO Council, bringing together two dozen CIOs from across all parts of the public sector to address common IT issues and improve public service delivery, is currently developing an architecture including lists of open standards and open source software.

Summary

  • the British procurement policy requires public agencies to actively consider open source solutions in making procurement decisions, giving them fair and equal consideration; yet procurement decisions will be made on the basis of best value for money solution to the business requirement, taking account of total lifetime cost of ownership of the solution, including exit and transition costs, after ensuring that solutions fulfil minimum and essential capability, security, scalability, transferability, support and manageability requirements;
  • the 2011 Government ICT Strategy aims to create a level playing field for open source software, for the government to procure open source solutions where appropriate, and to remove barriers to allow SMEs, the voluntary and community sector, and social enterprise organizations to participate in the government ICT marketplace; so a toolkit for procurers on best practice for evaluating the use of open source solutions was published, and several groups and platforms were established to assist with the deployment of open source solutions;
  • later that year, it was accompanied by the Strategic Implementation Plan, focused on standardising and centralising government ICT; open source, however, is only a small part of this plan; compliance to the policy and open source usage will be measured;
  • the Open Source Procurement Kit provides a set of documents making it easier for SMEs selling open source solutions to compete for government contracts;
  • a list containing dozens of open source software alternatives to proprietary applications, neither prescriptive nor definitive, has been published as part of the procurement kit;
  • despite all these ambitions, policies and plans, the UK has not been doing a good job with regard to the implementation of its open source strategy; although the open source policy has been there for a long time, administrations have not been following it; so the new strategy focusses on cultural problems on the work floor: the demand organisaton is lacking experience and capabilities;
  • just like in the commercial sector a decade ago, IT managers are afraid to lose their jobs when deploying open source, for even the enlightened people are surrounded by colleagues and senior managers that have no idea; to solve this problem with the middle management, and to empower people to explore these new ideas, the message that what they are doing is aligned to the ICT strategy is promoted;
  • the new government has brought in two new approaches: the mechanism of public transparency, and a mandatory check on IT projects over £5 million; furthermore, new contracts run for a maximum of one or two years, and contracts over £100 million in spend need to be split up;
  • good open source cases are promoted as an example implementation, but more case studies should be published;
  • the measuring, the spend control and the cases will in time give the administration a good over-all impression of where people are coming from and where they are migrating to; the insight in current use and demand of their software will also allow for a strong negotiation with the large software vendors;
  • the open source specialists at the administration are available for questions, help, and participation in open source projects;
  • where a twenty percent failure rate with the large software companies is seen as normal, the same rate with open source is seen as terrible; the difference is that in the latter case the twenty percent failure rate will rest on your shoulders; in practice, however, there is no difference: the impact of the risk and the cost are always with the customer; it is a myth that risk can be outsourced;
  • those who do not outsource and make their own IT decisions tend to have better values; or: intelligent customers make better IT decisions.

France: a new open source policy

Last month, the French government refreshed its open source policy. Prime Minister Jean-Marc Ayrault signed a guideline favouring the use of open source software by public administrations at all levels in France. It requires organisations to make a systematic review of free alternatives when doing development and major revisions of applications.

The policy was developed by a working group of Disic (Direction Interministérielle des Systèmes d'Information et de Communication de l'Etat, in French; the Interdepartmental Directorate for State ICT Systems), formed early last year to improve the quality, effectiveness, efficiency and reliability of government ICT services (in French).

The new 'Usage du logiciel libre dans l'administration' (in French; Guidelines for the use of free software in government) state that a long history of free software usage in administration has led to the development of skills and the capitalization of many positive experiences. Better sharing of knowledge and the development of common guidelines now allow the next step to be taken to increase operational efficiency and economy. So, on an interdepartmental level, Disic launched a working group, led by the CIO of the Ministry of Culture and Communication, to define new guidelines for the usage of free software in governmental departments.

Rational choice

The authors acknowledge that today the choice of free software in government is not an ideological commitment, but the result of a rational choice. Key motivations are the higher pressure on the investment and operational costs of information systems, together with a significant increase in demand, and the development of professionals skills and expertise instead of merely buying solutions.

Benefits from use cases in the public sector are:

  • open source software is not free, but is often less expensive, and its costs specifically depend on the criticality of the systems;
  • open source software is driven by need, minimizing unnecessary changes;
  • open source software allows customized versions adjusted to specific applications, and at the same time allows long-term support;
  • open source software facilitates experimentation and adaptation to volume of use;
    the absence of a user license allows it to vary greatly and freely;
  • open source software facilitates sharing between public agencies, bringing together emerging needs and capitalizing on existing packages;
  • open source software brings greater transparency in the specification and implementation of information systems under security policy, while requirements and cost are proportional to the chosen service level;
  • open source software allows for a truly competitive market, by purchasing services from companies that are on an equal footing with the developer community.

Points of attention

The current procurement policy acknowledges that the use of open source software is an opportunity to promote the principle of competition and openness to the public in the procurement of software and services. A court ruling by the state council (number 350431, on September 30, 2011) states that a contracting authority could organize a competition for the acquisition of open source software if it wanted to, without compromising the principles of public procurement.

However, open source software also has some limitations and some points to note:

  • open source software is linked to a community; it is therefore necessary to know and follow this community to ensure the sustainability and the maturity of the solution;
  • open source licenses do not constitute the absence of intellectual property rights, but another form of rights that must be managed, especially in development;
  • because to the end user branding and marketing are also part of software, open source software, which has no price, is sometimes considered worthless;
  • the opportunity to contribute to the development of open source software should not tempt you to add a lot of specific code, or you risk losing the link with the community and gain the burden of supporting an isolated solution over the long term;
  • participation in the open source community is inherent to the distribution of software code;
    users, especially professionals, cannot limit themselves only to benefit from open source; they have to contribute their gains in one form or another to maintain the model;
  • some publishers are at the edge of the open source model, offering an 'Enterprise' or 'Premium' version under a proprietary license, next to a 'Freemium' open source version that is usually lagging behind;
    these packages should be used with caution, as they may be carried by an employed maintainer rather than a community, and they may be brought back under a proprietary license.

IT environments

In addition to these general benefits, limitations, and points of attention, the French open source policy elaborates on some specific use cases and environments as well, taking into account the context of use, the number of stakeholders, the complexity of the system, and the consequential implications.

Environments friendly to open source:

  • existing and internationally recognized open source software with a large user base, like Linux, Apache, JBoss, Firefox, Thunderbird, OpenSSL, and Eclipse;
    this software can often be used immediately, and the cost reduction is straightforward;
    software replacing widely used solutions, however, requires change management for end users;
  • large-scale software deployments;
    for large systems or large numbers of users, thousands of licenses may result in substantial cost;
    it may be less expensive to directly support or improve existing open source software, and to participate in the community;
  • software deployed in a virtualised environment or entailing large variations in load;
    deployment in a virtualised environment simplifies the creation of logical servers and allows their number of processors to be adapted easily;
    proprietary licenses break that flexibility and simplicity, and require you to pay for the maximum load;
  • agile software development is opportunistic by principle, adding functionality driven by the needs of users;
    open source software allows you to evaluate, expand and deploy without worrying about intellectual property issues;
  • open source software is an alternative to proprietary software where the supplier has eliminated most competition;
    some packages provide high-end functionality and can replace proprietary software at limited cost; e.g. Linux;
    others provide somewhat less features, but can replace proprietary software where this specific functionality is not absolutely necessary; e.g. PostgreSQL;
    software vendors often favor the use of proprietary architecture components (i.e. operating systems and databases) by failing to ensure compatibility with open source software; choosing such a software solution may reduce the technological options and lead to additional hidden costs;
  • many public and private agencies share the same needs;
    the open source model can facilitate and benefit an association of stakeholders;
    Adullact (in French; Association des Développeurs et des Utilisateurs de Logiciels Libres pour l'Administration et les Collectivités Territoriales) offers a platform for united software development to civil servants, now hosting over 500 projects and more than 30 working groups;
  • deployment in various public and private agencies;
    some public functions require applications and systems to be open to all sorts of clients, enabling the integration of systems and the exchange of information between partners;
    the open source model provides a natural solution here; ease of management, cost reduction, and convenience of re-use are obvious.

Environments not friendly to open source:

  • if stakeholders are few and not easy to identify, it is hard to establish a community of contributors to share and pool their efforts;
  • comprehensive and monolithic software is a poor match for the open source model, as the principle of pooling requires a modular approach to development;
    furthermore, building blocks and modules are more accessible to new entrants, easier to re-use in many systems, and lighter to maintain.

Action lines

To facilitate the choice for open source solutions in government and to put these at the same level as other offers, while at the same time generating maximum economic efficiency and quality, the French government has established a number of action lines:

  • to establish an effective path to open source solutions;
    a converging (rationalizing) IT architecture covering both servers and office systems is defined and maintained at interdepartmental level; it defines references and indicates preferred solutions for specific use cases, and is updated every quarter;
    this architecture must be implemented in each department's infrastructure, and be part of each new project and major overhaul;
    each department has to participate in the further development of the architecture, stating regularly how it has been using the architecture, what it has been doing outside this framework, and how the lessons learned were fed back into the architecture;
  • to activate a network of expertise on software rationalization;
    experts are naturally willing to share, and should be enabled by linking them into a network; that way specialist skills can be pooled between departments; several tools have been developed for this purpose:
    • thematic working groups with regular meetings;
    • open source software days to engage new participants;
    • thematic mailing lists;
    • collaborative sites for thematic resource sharing;
  • to improve support for open source software in an economic way;
    maintenance and support for open source software can be scaled relative to the extent and criticality of the information systems;
    although many of the open source software deployments were done relying on nothing but support provided by the community, a number of uses require reactive support with commitment to results;
    open source software generally gives you more control in support compared to closed source, because the code is available for adjustment in house or by a chosen supplier;
  • to contribute to an orchestrated set of software packages;
    the government is currently contributing to a set of packages by donating patches to the community;
    but the government should also develop new functionality for packages that deliver the most savings; departments should systematically inject 5-10 percent of the avoided license cost in:
    • platforms supporting and easing the further development of packages;
    • funding research programmes to add advanced functionality;
    • funding scholarship funds to improve accessibility to software positions;
    • implementing a repository to share expertise and to develop packages, where contributions from the community are rewarded;
    • stimulate the involvement of professionals in particular communities, whether their contributions relate to software code, documentation or translation;
    the Ministry of the Interior (in French) and the SAE (Service des Achats de l'Etat, in French; the State Purchasing Department, part of the Ministry of Economy and Finance, in French) have set up a repository that could be the starting point for an interdepartmental portal for contributing and sharing;
  • to follow the major communities;
    it is essential for the government to maintain regular contact with the open source communities, to update its knowledge of the packages, to anticipate changes, and to collect requirements; this is the reverse of the commercial model, where software vendors take the lead;
    these contacts help in considering functionality and management tools and models that have not yet been covered, keep you involved in the long-term direction, and show you how the government might cover some of the community's needs;
  • to deploy credible alternatives and operational solutions to the solutions provided by large vendors;
    the government itself will develop information systems to promote competition in markets currently dominated by large international companies, to control operational costs and to maintain performance over time;
    deploying credible open source software packages like LibreOffice and PostgreSQL is part of this strategy;
  • to monitor the actual deployment of open source software on servers as well as in office systems;
    an annual analysis of software volumes and values, and their trends, will be conducted and published;
  • develop a culture of open source in the development of public information systems;
    the government must ensure that its software code is usable by other agencies, by reserving the right to release the code according to its own interests — under an open source license — regardless of the developer of the code;
    purchasers of software and lawyers should be brought together to draft administrative clauses, as part of a larger network of experts working on a true mastery of the subject in departments and CIO offices.

Implementation

To implement these action lines, open source software is supported and promoted at various levels. A team known as the 'core' concentrates on proposed policies at an interdepartmental level, validating options to be submitted to the CTSIC/CSIC committees (Comité (Technique) des SIC; (Technical) ICT Committee), and initiating actions related to interdepartmental governance (markets, software repositories, implementation guidelines and so on).

Additionally, there are thematic groups that are open to other organizations, bringing together experts in their particular fields, promoting the exchange of knowledge, growing competences, and offering guidance. At the moment, four groups have been identified:

  • mimO: open office;
  • mimOG: GLPI (Gestionnaire Libre de Parc Informatique, Free Management of Computer Equipment) and OCS (Open Computer and Software Inventory Next Generation, OCS inventory NG);
  • mimBD: databases;
  • mimOS: operating systems and infrastructure.

The specific mandates, organisation and means of these groups can be found in the annex to the policy.

Finally, to support this approach, various additional actions should be taken at interdepartmental and departmental level:

  • an architecture converging to open source packages, by the technical staff of each department;
  • the investigation of open source alternatives for each new project and major application overhaul, especially when it concerns database systems;
  • participation in the 'core' group is highly recommended to each department, to increase the dynamics of the group;
  • an explicit definition of instructions at each department, on the involvement of experts in sharing their knowledge and steering the community;
  • an opportunity study by the SAE on the revision of the Cahier des Clauses Administratives Générales (in French; GCC, General Conditions of Contract) for ICT, to establish an option for code to be released, as well as defining the obligation for service providers to use open source software;
  • a list of open source reference implementations for standard formats, that will be part of the general interopability framework; the formats will have to be based on open standards;
  • the dissemination of best practices, particularly for office environments, so open source software will not be harder to use than proprietary software.

Conclusions

Public administrations as well as open source suppliers say that the right procurement policies are currently in place. That, however, is not enough to allow supply and demand to meet each other directly. The gap between the two is currently bridged by system integrators who generally do not have in-depth expertise in open source or a connection with the developer community. What they do contribute at the moment, however, is the business continuity, professional services and management skills that the small open source specialist companies are unable to provide.

We see a similar situation in the public agencies. The right people, familiar with the huge cost savings and other benefits open source could bring, are at the right positions. But there is a lot of inertia, making it hard for public agencies to take in this new model.