The next generation of open source software procurement models

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