Swedish Framework Agreement Overcomes FUD, Inertia, Risks and Other Barriers

One year ago, the new Swedish framework agreement for the procurement of open source became active. Five suppliers were contracted to provide software and services. Central government, the public educational sector, all twenty county councils, and 225 out of the 290 Swedish municipalities are participating. They call off mini competitions for contracts the suppliers then have to battle for. This model differs from the recommendations made in the European 'Guideline on public procurement of Open Source Software', aiming to overcome current barriers and increase the use of open source.

The Swedish framework agreement 'Öppna programvaror 2010' (Open Source Software 2010) has been active for almost a year now. It constitutes an agreement between the national public sector and five IT suppliers for the procurement of open source software and associated services. The framework can be used by all parts of the central government, the public education sector, all twenty county councils, and 225 out of the 290 Swedish municipalities."

"By law, the government cannot decide what a municipality or county council should do," Daniel Melin explains. He is Procurement Officer ICT at the Swedish Legal, Financial and Administrative Services Agency (Kammarkollegiet). "So for each framework agreement we procure we ask each of those to give up their decision-making power to us. In this case all county councils and 225 municipalities joined." That does not imply that it's mandatory to use the agreement: "Usually the customers use the framework if they can. They don't have to, but in that case they would probably end up doing a less good deal."

The current number of participating municipalities is roughly equivalent to the number participating in the previous framework agreement. One of the problems the other municipalities had is the question which department should take up this request. "Most of them missed our question due to internal mishandling. Is this IT? Is this procurement?" Then the question bounced back and forth until the deadline was missed.

The Framework Agreement

According to Melin, this framework agreement is the first one for the procurement of open source software in Europe. In fact, its origins date back to a similar framework that run from 2007 to 2011. "The agreement was created by the National Procurement Services department (NPS). The previous framework called 'Programvaror och tjänster 2007 — Öppna programvaror' had roughly the same scope and suppliers. That contract ended on March 31, 2011. 'Öppna programvaror 2010' started on April 1, 2011, and is valid for two years, with an option for another two."

Last year the contracts were worth about six million euros in turnover. According to Melin, annual growth is 10-15 percent: "The agreement is mostly used by those who have seen the light." To put these numbers into perspective: "There exists a parallel framework agreement called 'Licensförsörjning 2010' that customers can use to buy any kind of software (including open source). That agreement has got a yearly turnover close to 100 million euros."

"The drawback of this dual solution is that the customers cannot compare open to proprietary software via a mini competition. They have to choose upfront which way to go. However, if we hadn't organized it this way and instead had created one large agreement called 'Software', smaller companies wouldn't have been able to participate, and then the framework would have been populated by the largest companies selling only the software customers ask for, or the software that would give the supplier the highest margin. That would have resulted in close to zero open source sales."

History and Rationale

Being responsible for the coordination of procurement for the public sector, the NPS has to make sure that optimum conditions are created for the acquisition and use of IT. And not only for common features and solutions, but also for innovation and technology-neutral solutions in particular.

To determine the best possible terms for acquisition, a feasibility study was conducted to identify the required scope, focus and structure of the procurement of software and services. It looked into various delivery models serving eGovernment, operations, and consulting services:

• licenses: license management, Software Asset Management (SAM);
  installation, configuration, customization and support
• open source: supply, integration, and project management
• office productivity from the cloud (SaaS: Software-as-a-Service)

The study found that the customers were content with the current suppliers, but they saw no added value in the distinction of five different categories that was part of the old setup. As a result, the procurement model has been reduced to two parallel frameworks for the acquisition of software and services.

Two major changes were made specifically to the open source procurement model. First, under the old procurement directive customers could pick and choose among the suppliers, while the new framework requires mini competitions. Second, the old agreement did not protect the customers from 'Fear, Uncertainty, and Doubt' (FUD), a phrase related to Microsoft's marketing practices of defaming open source. As can be seen below in the section on the open source specific contract terms, the new agreement secures the availability of support and moves risks related to intellectual property (for example, issues of licensing, copyright, and patents) to the suppliers.

The rationale behind this model is the creation of competition between the suppliers, the minimization of risks for the customers, and the provision of a way for software development paid for with tax money to be given back to the community.

Explicitly excluded from this framework contract is the procurement of:

• Software-as-a-Service
• appliances (hardware and software combined in a ready-to-run system)
• sector-specific applications
• firmware
• embedded systems

Although the feasibility study also identified an interest in software functionality delivered from the cloud (SaaS), Melin admits that current support is very limited. "But I am responsible for the upcoming procurement 'Kontorsstöd som molntjänst' (Office-as-a-Service), where we will set up a framework agreement for cloud-based services, including e-mail, calendaring, word processing and such."

The Call for Tender

When calling for tender (in Swedish), the NPS explicitly aimed to bring together public sector demand and open source software and services. The agency was looking for a maximum of six open source suppliers for a period of two plus two years. The primary suppliers could bring in as many subcontractors as they saw fit.

These are the groups of software covered by the framework:

• office support: office productivity, collaboration, communication, project management
• information supply: case management, document management, work flow
• operating systems, access control
• security software: scanning, filtering, network security, backup, encryption
• operational support: system management, deployment, help desk, directory services, resource management, energy measurement
• asset management for software (SAM) and hardware
• middleware: message busses/queues, application servers, web servers, SOA (Service-Oriented Architecture), transaction management, legacy integration, Server-Based Computing (SBC)
• development tools: Integrated Development Environments (IDEs), compilers, test tools, version management, modeling, development frameworks, Object-Relational Mapping (ORM), package management
• databases
• statistics software: data warehousing, data mining, data visualization, spreadsheet tools, report generators, web statistics, questionnaire and statistical tools

and associated services:

• installation of the software
• implementation in the customer's existing environment
• integration
• management: customizations
• migration from the existing installation to the purchased software
• support: assistance to end users and support for IT managers
• maintenance: continuous updates and upgrades
• training for end users

These conditions were included in the requirements of the call:

• bidders shall quote only open source software
• demonstrable involvement in the open source community
• active contributions to open source software
• expertise in legal implications
• experience in training of users and technical personnel

And all that for at least one package for each of the software groups listed above.

The framework leaves open the possibility of procuring open source software without any services. An example would be the acquisition of subscriptions to RHEL, a branded enterprise Linux distribution that is also freely downloadable as CentOS and Scientific Linux.

The Selected Suppliers

The suppliers were above all selected on their capability to provide competences and comfort, and their ability to deliver to the customers. Subcontractors without consultants were unceremoniously rejected. From the seven tenderers two were ultimately dismissed; their scores were substantially lower that those of the other five companies (around 20, compared to the 60-90 range of the others). According to the NPS, the remaining five companies would provide sufficient contention for the mini competitions.

The suppliers fulfilling the new framework agreement are the Arctic Group, Init, Pro4u Open Source, RedBridge, and Redpill Linpro, at their turn subcontracting 75 companies in total to provide all the required competences and services. It comes as no surprise that these suppliers are not the typical companies fulfilling government contracts. Their sizes vary from a one-man shop (with a lot of subcontractors) to 180 employees.

Redpill Linpro is the combined operation of Sweden's and Norway's largest open source companies. Redbridge was started by former employees of Oracle and comes from a server-side background. Init is a smaller, technology-driven company. The Arctic group is an umbrella company which sells open source consultants from other companies. And Pro4U is a larger consulting company that has just started up an open source unit. Since all of these companies were already participating in the former framework agreement, they do have a long history of working with the Swedish public sector.

Mini Competitions

A public organization wanting to procure through the framework agreement creates a mini competition between the main suppliers. All five companies then have to come up with a proposal. The customer's request specifies the requirements, including topics such as:

• functionality
• certifications
• documentation
• help functionality
• licenses
• pricing
• time/period and place of implementation
• the ability to deliver software and services
• support levels
• competences and references
• languages spoken by consultants
• security-screened consultants
• information model and information structure
• information security
• programming language
• development methods
• work processes
• changes/integration/adaptions/customizations
• integration
• accessibility (WCAG)
• infrastructure
• hardware platform
• virtualization
• energy efficiency

Maximum hourly rates for the various skill levels have been set in the framework agreement for each of the main suppliers.

Before the call-off the customer is allowed to consult the suppliers, to get a good idea of the available solutions and to be certain they can deliver. The extensive description of the customer's needs allows the suppliers to make sure their subcontractors will be able to deliver.

Although every subcontractor must be connected to one or more primary suppliers at the time of the tender, suppliers can switch subcontractors later. Furthermore, suppliers have to be completely transparent about the subcontractors they will be using and what services these subcontractors will provide to the customer.

"The mini competitions create contention between the suppliers," Melin explains, "Since all of the companies can provide almost all kinds of open source software, there would be no use in having multiple suppliers in a hierarchy. The one on the top would almost always be able to handle all customers and their needs. In the end, that would make this supplier 'fat and lazy'."

So the mini competition should be organized in such a way as to warrant a fair, even-handed battle for the contract. To facilitate this, NPS has made available a template for the customers to use.

Terms and Conditions

When procuring software and services under the framework agreement, a predefined set of terms and conditions automatically becomes part of the contract. These are comparable to conditions traditionally used in IT procurement, apart from the following terms specifically related to open source:

• The customer receives non-exclusive and indefinite rights to the Result, including a right to copy, modify, correct, and further develop the Result. The customer has the right to hire third parties in order to utilize the Result in accordance with the specified terms of use.
• The supplier must indicate to what extent the software license affects the customer's rights to the Result.
• The supplier shall within 30 days after the customer's acceptance of delivery provide all changes and additions back to the relevant communities. When the supplier provides the changes and additions, they must adhere to the conditions and practices of the community or company behind the software.
• The supplier is not entitled to transfer or assign the rights to the Result to the customer on terms that restrict, or goes beyond, the terms in the software license.
• Results in the form of source code, and any documents pertaining to the source code, delivered to the customer shall be published, publicly available, on the supplier's public website. The supplier shall publish the Results within 30 days after the customer's acceptance of delivery and be available throughout the Framework Agreement period.
• The supplier is responsible for ensuring that they have obtained the rights necessary for the execution of the assignment and delivery. The Supplier is also responsible for ensuring that the customer is not required to have any additional license or pay royalty payments for the customer's use of the Result.

In addition, a model contract has been made available. It can serve as a starting point for the substantive agreement, elaborating the details in various annexes.

OSS Licenses and Procurement Guidelines

A contract entails the purchase of free software with or without associated services. The framework defines open source software as code available under a license approved by the OSI (Open Source Initiative). Besides promoting free software, this organization maintains a list of licenses that have been checked against the Open Source Definition (OSD). In that sense the framework builds on the work already done in the community.

However, this approach differs from the recommendations made in the European 'Guideline on public procurement of Open Source Software', which describes explicit calls for open source software as bad practice. The guideline discourages organizations from issuing calls for tender for the supply and service or installation of specific open source software packages, or even stating 'open source' as one of the selection criteria. Purchasing a specific open source software application — i.e. the supply as part of installation, integration or support — may be out of line with regulations (but less so than issuing calls for tenders for specific, named proprietary software applications, a common practice). The authors of the guideline recommend best practice procurement based on the definition of functional and technical requirements, which may include properties that are equivalent to the characteristics of open source software or open standards, i.e. in terms of interoperability and needs of the customer, or by asking for specific standards or standards from a list.

The following, for example, could be ways to describe open source without explicitly using this term:

• the ownership of the software is transferred to the customer, with no restrictions on what the customer can do with the software; or the software may be used for any purpose (without transfer of ownership)
• the customer or a third party of his choice (or any member of the public) may study the source code
• the customer or a third party of his choice may modify the software
• the customer can distribute the software, with source code and modifications, to anyone of his choice and provide recipients with the same abilities to use, study, modify, and redistribute.

When specifically looking for the right to redistribute, the guideline names another three terms (based on the Spanish National Interoperability Framework, NIF) that could be part of the requirements:

• allow the free use/reuse of these applications
• prevent the appropriation of the software by a third party (copyleft)
• protect the administration from liability, support and warranty obligations.

These would allow the software to be distributed under the European Union Public License (EUPL).

A Different Route

The NPS, however, chose a different route. "We do not want to define 'open source' or 'free software'," Melin explains. "We rely on OSI to provide that. Everyone agrees that it's good practice to do so. But you have to split procurement and create mini competitions from a framework agreement. If you do your own procurement, I would suggest composing a functional requirements specification and favoring items that lessens lock-in. Requiring an open source license for the software you procure is not against the public procurement directive and sometimes there can be good reasons to do so."

In the latter case, the guideline recommends that open source requirements are placed not in the functional specifications, but as separate requirements or weighted criteria in the contract documents (cahier des charges) or the contract subject matter description.

Melin emphasizes that to the best of his knowledge Sweden is the only country with a framework agreement for open source: "So we are creating our own path here. We weren't even aware of the existence of the 'Guideline on Public Procurement of Open Source Software'. Furthermore, the procurement of a contract is radically different from procuring a framework." On this journey he could use more support from the government. "In Sweden there is no outspoken support for open source at all. So some organizations are very well aware of open source and prefer it, others just buy whatever fits their needs."

Unfortunately, only few Swedish organizations have recognized the true value of open source. Most of them use the framework agreement to buy support contracts for RedHat (providing an enterprise Linux distribution), JBoss (a Java-based application server), Liferay (a Java-based intranet/extranet portal), MySQL (a relational database), Mule (a Java-based enterprise service bus), SugarCRM (providing a PHP-based CRM application), and Alfresco (providing a Java-based web CMS). "Very few seem to be interested in reducing their lock-in."

"However, the Swedish governmental model implies that each municipality, county council or agency can buy IT pretty much as they see fit. Central government has very little to say about it. I would like to see more direction from the government pushing for open source software, so the framework agreement would be used even more."

Guideline on Public Procurement of Open Source Software

The 'Guideline on Public Procurement of Open Source Software', published in June 2010, promotes the deployment of open source as a way to reduce costs, and to increase transparency and sustainability. Technology-neutral solutions create independence from specific vendor and providers, avoiding vendor lock-in through proprietary technologies and standards.

Taking interoperability and openness as a starting point, closed source software is, by definition, expensive over the long term. "Supporting technologies without considering their degree of openness and their ability to foster a fully competitive market is harmful to competition and net social and economic welfare. So, even while software based on open standards may not always be available, public agencies should encourage its development, and indicate their preference for open standards to vendors."

At the same time the authors recognize that at a European level there are currently no policies dealing with open source and open standards. "Public sector consumers of software have an obligation to support interoperability, transparency and flexibility, as well as economical use of public funds. Agencies should not require citizens to purchase or use systems from specific vendors in order to access public services." These are the principles laid down in the 'European Interoperability Framework' (EIF), a high-level architecture document produced by IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens), the predecessor of the current Interoperability Solutions for European Public Administrations (ISA). The further development of the framework, however, bogged down on its way to version 2 due to high pressure from proprietary software vendors.

The guideline is based on the model presented in the 2007 Dutch government action plan 'Netherlands in Open Connection' (in Dutch), "expressing an explicit 'preference for open source software in the case of equal suitability'", and the subsequential 2008 action plan 'The Acquisition of (Open Source) Software'. The guideline emphasizes that although "discrimination between individual vendors goes against numerous regulations and procurement principles, preference within a particular tender towards a specific business model is generally accepted", thereby defining open source as a business model. "

The purpose of this guideline is to allow individual public agencies at the regional, national or local level to acquire open source software, even if there is no policy in place regarding open source." "Justification for this guideline is provided by the existence of widespread 'poor practices' in public procurement that lead to non-transparent, anti-competitive discrimination in software procurement. This discrimination is in favor of proprietary software, and typically, in favor of specific proprietary products and their vendors." "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 organizational needs."

According to the European policy, open standards can be part of the requirements; open source software cannot. That's why the authors of the guideline recommend defining open source in terms of code being publicly available, modifiable, and re-distributable.

Spain: "Same Goals But Different Paths"

The people at the Spanish CENATIC (National Competency Centre for the Application of Open Source Technologies) see a bright future for the Swedisch open source procurement model: "Any action undertaken to provide a level playground for open source software in public tenders is both needed and welcomed. The Swedish model focuses on the elimination of the main barrier open source is facing: the technical difficulties that might be associated with a tender due to the lack of specific knowledge. The framework is well suited for this environment and we are convinced it will be successful. An improvement would be to not contract the same companies but to foster knowledge transfer to the IT sector in order to increase competition, for example on a yearly basis."

At the same time, CENATIC emphasizes that the Spanish environment differs largely from the Swedish: "So we seek the same goals but through different paths. We too focus on giving open source the same chances in tenders that other software already has. But our strategy is based on legislation for reuse, sharing, and collaboration on IT systems between public administrations levering on interoperability." "

Following European recommendations, since 2007 Spain has issued laws binding public administrations to acquire software based on open standards, to look for reusable solutions before buying licenses or taking up new developments, and to facilitate code sharing between public administrations. Spain has also developed an application repository for free reuse between public administrations ruled by the Technology Transfer Centre of the Department of Public Administration. We also have CENATIC (in Spanish), a public foundation aiming to increase knowledge and awareness of open source technology, policies, and methodologies in Spain. These strategic lines established by the Spanish central government have been embraced by several autonomous communities providing specific ways for reuse, sharing, and collaboration in their regions. Special interest has been raised by the Basque Country decree for openness and reuse, and the Andalusian public administration repositories."

Even though the CENATIC spokesman does not see any inconveniences in the Swedish approach, he finds it more sustainable and suitable for Spain to promote the use of open source software through specific legislation: "Despite having the same goals, we are facing different problems, requiring a different approach. I'm afraid that the Swedish model could not be applied in Spain due to our tender legislation. The preselection of a limited group of providers would be difficult to fit in the Spanish public contract law."

"But we do have various initiatives to facilitate the procurement of open source software by public administrations, especially for municipalities where a significant lack of technical 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 providing models for documents and specifications. Also, last January, CENATIC launched the Open Source Legal Community, a legal community for 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."

The UK: An Informational List of Open Source Suppliers

An open source specific framework agreement like the Swedish model encompasses, would not fit the current UK policies. "Our government will not produce an approved list solely for open source suppliers from whom purchases can be made," says Niki Barrows, member of the Strategy & Architecture Team at the Office of the CIO of the Home Office. "To be in line with our own policy any new frameworks for software procurement will be open to suppliers of both open and closed products. But we may produce a list of suppliers, similar to the list of open source software alternatives we created, simply for information purposes."

After making the use of open standards mandatory through its public procurement policy (recently restated), the British Cabinet Office now requires government departments and agencies to actively consider open source solutions in making procurement decisions. "There is no current intention in the UK to mandate the use of open source software or do anything other than give it fair and equal consideration as part of a procurement exercise," Barrows emphasizes. "Procurement decisions will continue to be made on the basis of best value for money. A Total Cost of Ownership model is being developed to help with a fair evaluation of a wider set of costs than might currently be considered."

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 for the towns of Windsor and Maidenhead responsible for IT policy, and now as the Director of ICT Futures advising at the Efficiency and Reform Group (ERG) within the Cabinet Office.

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 Gross Domestic Product, 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 very 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.

The road map for open source sketched in the "Better for Less" report starts with a transition to ODF (OpenDocument Format), followed by a fully open source software based desktop. 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 policymakers 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, an elaborated Government ICT Strategy 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.

"The UK open source policy dates back to 2004," Barrows explains. "It has been restated several times and there have been action plans aimed at delivering a level playing field for open source solutions. The actions in the 2011 Government ICT Strategy attempted to identify and address the reasons why we do not yet appear to have reached our desired goal of a level playing field."

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. "The information in the toolkit aims to let people know that there are other solutions out there," says Barrows, "and to give procurers the information they need to fairly evaluate all options."

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. ICT Futures is currently running an open consultation on the use of open standards for interoperability, data and document formats.

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. An updated version of this document is currently being developed."