---
title: Open source toolkit for procuring standard software
author:
- Maurice Hendriks
- In collaboration with all contributors
toc: true
toc-depth: 2
toc-title: "Inhoud"
toc-own-page: true
footer-left: "Open source toolkit for procuring standard software"
header-left: "​"
header-center: "​"
header-right: "​"
titlepage: true
titlepage-background: ./docs/assets/img/cover.pdf
titlepage-rule-color: 'ffffff'
page-background: ./docs/assets/img/cover.pdf
page-background-opacity: 1
license: Creative Commons Attribution 4.0 International
hide:
- path
- navigation
show:
- breadcrumb
---

<style>
.oud, .nieuw {
}

.oud {
background: #f9dfdd;
}

.nieuw {
background: #e1edda;
}

.variabele {
background: #e6e6e6;
color: #535353;
}
</style>

>[!Note] Explanation
>All text in these blocks will not appear in the published document on GitHub Pages, but are intended as an explanation for you as a contributor here on HackMD.

>[!Note] Participate?
>:100: The goal of this document is to collaboratively develop a fully elaborated ambition ladder that will offer a framework for open source in tenders or contracting. Everyone is free to participate in this document. Based on mutual trust.
> \
> \
> You have two options in this document:
> 1. Leave a comment;
> 2. Make a text suggestion.
>
> Select a piece of text. A small menu will open where you can choose "*Comment*", "*Suggest Edit*", "*Edit from here*" or "*Copy link*".
> \
> \
> Participating via GitHub is not possible and any suggestion there will not be addressed. Instead, you can participate on HackMD with or without your GitHub account.
> \
> \
> Want to be attributed as a contributor in the list of contributors at the bottom of this document? Then put your name and optionally your organization in a comment field under that chapter. If you want your name to link to an online profile, please let us know.

>[!Important]Administrator
>:cop: Maurice Hendriks

>[!Tip]GitHub account?
>:star: For everyone with a GitHub account. You can log in here via that account so that your contributions are traceable.

> [!Note] Community call
>
> {%hackmd 09HDRFB7TqeWsi1T2YTTKw %}

# Introduction

> [!Note]
> The goal of this document is to encourage joint reflection on the toolkit for open-source procurement of standard software. It was initially drafted by Maurice Hendriks, Open Source Expert at the Ministry of Health, Welfare and Sport. The insights are based on practical experience with open-source procurement within the Dutch central government.

Open-source software offers unique opportunities for government organizations and other contracting authorities. Yet, its adoption through procurement processes often stalls. This is not due to a lack of quality or functionality in open-source software, but because procurement procedures are still too often designed according to the rules of closed ecosystems. As a result, suppliers of closed-source software frequently have a disproportionate advantage.

This document demonstrates how small, targeted adjustments can help create a level playing field while at the same time fostering innovation, flexibility, and social value.

The Dutch Public Procurement Act 2012 2012 (Aw) requires:

* Equal treatment (Art. 1.10b Aw 2012)
* Non-discrimination (Art. 1.8 Aw 2012)
* Proportionality (Art. 2.52, 3.50a Aw 2012)
* Transparency (Art. 1.10b Aw 2012)

When procurement procedures are applied in a way that primarily—or even exclusively—favors closed-source software, this may conflict with the fundamental principles of the Dutch Public Procurement Act. In such cases, the contracting authority risks legal challenges or annulment of the award decision (Chapter 4.3 Aw 2012).

{%hackmd Lf8vRdFhShOiVX83M3pY5Q %}

# Open ecosystems

Characteristics

- **Open access**: Standards, processes, and technologies are freely available.
- **Interoperability**: Components can be exchanged through open standards.
- **Collaboration**: Innovation and problem-solving take place through co-creation.

Software such as LibreOffice and Nextcloud illustrate this well. LibreOffice is managed by The Document Foundation, a non-profit organization responsible for governance, certification, and financial oversight. Developers, companies, and individuals contribute voluntarily to the continued development and improvement of the product. Nextcloud operates under a steward-owned model, in which the open-source mission and vision are firmly embedded in the organization. For both, there exists a network of service providers who handle implementation, management, and support.

In contrast to closed ecosystems, where software often functions optimally only within the suite of a single vendor—and where updates and maintenance depend entirely on that vendor—the open ecosystem offers freedom. Organizations can choose their own service providers, decide which adaptations to make, and determine how software is integrated. Moreover, improvements can benefit the entire community, as was the case when the [Ministry of Defence](https://tweakers.net/nieuws/109699/ministerie-van-defensie-maakte-sha256-hashes-mogelijk-in-libreoffice.html) added SHA-256 hashing support to LibreOffice.

# What You Can Do

The steps required to make your procurement genuinely open-source-friendly are relatively small. The most important quality a contracting authority should bring is flexibility. If you approach procurement flexibly, you gain flexibility in return—along with a high degree of sovereignty and autonomy.

* Contract services related to an open-source product.
* Consider splitting your procurement into separate lots.
* Use a growth path for (non-)functional requirements.
* Include open-source benefits in sub-award criteria.
* Integrate open-source into corporate social responsibility and sustainability goals.

One of the key principles of the Dutch Public Procurement Act is proportionality. This principle requires that the procurement requirements are in proportionate to the subject of the contract. An example: A municipality requires that bidders have completed at least ten comparable projects in the past five years, each worth a minimum of €5 million, and employ at least fifty people. This excludes smaller and innovative suppliers (including open-source providers), even though they could successfully carry out the assignment.

:::info
**Market Consultation**

Before applying these strategies, it is wise to consult the market. A market consultation allows you to assess the feasibility of your plans. Is the proposed splitting of the contract logical for the market? Is the growth path realistic? Which service providers are available for the open-source product you plan to use?

These insights help you design a procurement that fits the market and thereby increase the likelihood of a successful outcome.
:::

## Contract Services Related to an Open-Source Product

Open-source software can be used directly without an obligation to procure, because the Dutch Public Procurement Act applies only to works, supplies, and services (Art. 1.4 Aw 2012). Freely available source code may therefore be downloaded and used. The associated services—such as implementation, further development, support, or training—can then be procured separately. This approach gives organizations maximum control over the software they wish to use.

It is essential, however, that the choice for a specific open-source solution is motivated objectively and transparently. Clearly explain why this software best meets your needs. This can relate to functional requirements (specific business needs) as well as non-functional requirements such as interoperability, sovereignty, flexibility, or alignment with long-term strategy. In line with the principles of equality, non-discrimination, proportionality, and transparency (Arts. 1.8–1.10 Aw 2012), other market participants must be able to understand why their solution was not chosen if they believe they can provide a comparable solution.

If multiple suitable solutions are available on the market, it is advisable to verify through a market consultation whether the chosen solution indeed best meets the (non-)functional requirements. This ensures that the selection of the open-source solution is objectively defensible and that the procurement can withstand legal scrutiny.

:::info
**Reference**

This method of acquiring open-source software was first described by Mathieu Paapst, who called it the “download scenario.” This scenario was also discussed in more detail in the document [Public Values and Rights in ICT Procurement](https://open.overheid.nl/documenten/ronl-d51b01162a7e1ba340babc000b570e432fc343c8/pdf) (Only available in Dutch).
:::

## Consider Splitting Your Procurement into Separate Lots

ICT-procurements almost always consist of a combination of software and related services (such as implementation, management, maintenance, support, and training). By splitting the contract into separate lots, the procurement can be made accessible to both closed-ecosystem providers and providers operating within an open ecosystem. In open ecosystems, different service providers often deliver only part of the overall service. Splitting the contract thus promotes competition and innovation.

The Dutch Public Procurement Act stipulates that contracts should not be unnecessarily combined (Art. 1.5 Aw 2012), unless combining them is appropriate. Procurements also should not be unnecessarily split with the intent of staying below the European procurement threshold. The threshold is differs for each kind of procurement and change often. For the current tresholds see [this](https://www.pianoo.nl/nl/regelgeving/drempelbedragen-europees-aanbesteden) page at PIANOo.

It is recommended to divide your procurement into logical subcontracts. For example, the procurement could be split into four lots:

1. Licenses or contracts
2. Management, implementation, maintenance, and support
3. Further development
4. Training

Design the lots so that providers from both open and closed ecosystems can bid for individual lots or the entire package. If certain lots are not successfully filled, it is still possible to select a bidder who can deliver the full package. In this way, a single procurement can accommodate both approaches without the need to start a new procurement.

It is also important to explain clearly (Art. 2.10 Aw 2012):

* Why these particular lots were chosen and how they fit the procurement;
* That providers may bid for one or more lots;
* The rules that will be used to evaluate the bids.

## Use a Growth Path for (Non-)Functional Requirements

After completing a procurement, it often takes significant time and effort to achieve a successful delivery: implementation, training, data migration, and configuration all follow after contracting.

Software rarely meets 100% of the stated requirements and wishes. Closed-source software often contains significantly more functionality than strictly necessary, whereas open-source software initially tends to focus on the most commonly used standard features. In the first case, there is a risk of paying for unnecessary functions; in the second, additional development may be required.

The Dutch Public Procurement Act allows for a pragmatic approach to this. It is permitted to define only those requirements as knock-out criteria that are truly essential for immediate operation. Additional functionalities can be included in a roadmap, provided this is communicated transparently in advance (Art. 1.9 Aw 2012).

Including a growth path in contracts makes it possible to phase in certain (non-)functional requirements. Examples include:
* Migrating from a trans-Atlantic cloud provider to a European sovereign cloud provider;
* Gradually implementing Dutch government compliance standards, or explaining how the equivalent is provided;
* Adding specific functionalities, such as when the Ministry of Defence added SHA-256 hashing to LibreOffice in 2016;
* Obtaining the necessary certifications.

The advantage of investing in the further development of open-source software is that improvements benefit not only your organization but also other users directly. A solution that meets 80% of your needs today can quickly grow to 90% or more through joint investment. This creates a sustainable cycle of mutual reinforcement within the open ecosystem.

## Incorporate Open-Source Advantages into Sub-Award Criteria

When multiple bids meet the minimum functional and non-functional requirements of a procurement, the contracting authority determines who is awarded the contract based on award criteria. The minimum requirements are set out in the Program of Requirements and the Descriptive Document. To differentiate between bids that meet these basic requirements, sub-award criteria are used.

Sub-award criteria represent the qualitative aspects used to assess bids. Examples include planning, project plan, sustainability, service, aesthetic features, or innovative capabilities. The contracting authority determines the criteria, the associated scoring, and the weight of each criterion. This ensures that price alone does not determine the award. [Source: PIANOo](https://www.pianoo.nl/nl/inkoopproces/fase-1-voorbereiden/keuze-gunningscriterium-en-opstellen-subgunningscriteria)
It is important to note that both price and quality are also award criteria in themselves.

By using sub-award criteria smartly, the benefits of open source can be highlighted. Open-source advantages can include faster bug resolution, higher-quality software development, greater opportunities for collaboration with the supplier, and increased transparency regarding how the product works. In contrast, closed-source suppliers may emphasize ready-made solutions and full service by a single party. It is crucial that the sub-award criteria are relevant to your procurement and serve a direct purpose.

:::info
**Practical Example – PGO Procurement, MinVWS**

* **Project Plan (100 points)**: evaluated on clarity, feasibility, concreteness, and completeness of the proposed plan.
* **Innovativeness (250 points)**: evaluated on the level of innovation and contribution to the further development of the MedMij-infrastructure, including the use of open source.
:::

By giving Innovativeness a higher weight than the Approach Plan, open-source benefits are more prominently recognized.

:::info
**Example – Collaboration (max. 500 points)**

The contractor demonstrates the ability to collaborate effectively. Points are awarded based on:

* Participation in relevant open-source communities and the nature of that participation;
* Contributions to projects relevant to the assignment;
* Duration and intensity of involvement in those communities;
* How responsibility within the supply chain is managed.
:::

This encourages suppliers to actively contribute to open-source software while simultaneously improving their score in the procurement.

By structuring sub-award criteria in this way, a fair playing field is created within a single procurement for both closed and open ecosystems, while open-source suppliers can be specifically encouraged.

## Integrating Open Source into CSR Goals

The Dutch government holds a unique position: with an annual procurement volume of €116 billion, the public sector has the ability to steer markets and actively support societal goals. The Dutch government has signed the Manifesto for Socially Responsible Commissioning and Procurement, which provides a framework for embedding sustainability, social, and ethical objectives in procurement. [Source: PIANOo](https://www.pianoo.nl/nl/themas/maatschappelijk-verantwoord-inkopen/manifest-maatschappelijk-verantwoord-opdrachtgeven-en)

In procurement, objectives are generally divided into two categories:

**Prevention**: limiting risks or avoiding harmful effects, for example:

- Preventing child labor or other forms of exploitation
- Avoiding disproportionate environmental damage
- Preventing trade or cooperation with sanctioned countries or individuals

**Promotion**: stimulating positive societal impact, for example:

- Social Return on Investment (SROI)
- Sustainability and circularity
- Innovative and inclusive work practices

These objectives can be incorporated into procurements by:

- Allocating a percentage of the contract value to CSR objectives;
- Defining specific non-functional requirements directly related to the product or service.

Example: For a SaaS-solution, a requirement may be set that the data center runs on renewable energy.

Open source is not yet applied as a CSR instrument—a missed opportunity, particularly for ICT-procurements. Open source directly serves the public interest by making knowledge and functionality available to everyone.

The benefits of embracing open source to achieve CSR objectives are numerous:

* **Inclusivity**: Freely available software lowers barriers to participation in the digital society and offers opportunities for everyone, regardless of financial means.
* **Sustainability**: Open-source software can extend the lifespan of hardware, as it often runs on older devices. This supports the circular economy and reduces e-waste.
* **Supply Chain Responsibility**: The open and collaborative nature of open source fosters shared responsibility for software quality and security.
* **Economic Value**: A European Union study found that every €1 billion invested in open source yields a return of [€65 to €95 billion](https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and). Thanks to open source, suppliers spend 3.5 times less on software development.

Integrating open source into procurement can follow a model similar to Social Return on Investment (SROI). Instead of reserving a percentage of the contract value for SROI, a percentage can be reserved for contributions to the open-source community. This can be achieved in various ways, such as:

* **Donations**: Providing financial support to foundations that sustain open-source projects, such as the [NLnet Foundation](https://https://nlnet.nl/) or the [Sovereign Tech Fund](https://www.sovereign.tech/).
* **Publication**: Open source publishing the source code of in-house software.
* **Development Capacity**: Assigning developers to contribute to existing open-source projects, for example by fixing bugs or adding new features.
* **Education**: Organizing workshops and training sessions on open-source software use, for example in libraries or funding university programs to expand their open source training components.

Using open source as a CSR instrument gives suppliers an additional way to meet their CSR targets—one that is particularly relevant to the ICT market. At the same time, it provides an accessible way for companies to contribute to societal goals and benefit from the advantages of open source, without imposing a requirement to use open source software.

# Recommendations

## Choose a Balanced Approach

Procurement is always an exercise in balance. On the one hand, as a contracting authority, you want as much certainty as possible that you are selecting exactly the right bidder—one whose offer meets 100% of your (non-)functional requirements at the optimal price. The ideal scenario—the golden egg—doesn’t exist. There will always be choices and trade-offs to make.

On the other hand, suppliers are entirely free to decide whether or not to participate in a procurement. For them, it is essential that the chance of winning is realistic. If the requirements are too high, too strict, or too one-sided, suppliers may drop out. In the worst case, this can lead to a failed procurement with no bidders at all.

The aim of this document is therefore to provide guidance for a balanced approach—one that creates a level playing field for both open-source and closed-source suppliers. This means conducting procurements without favoring or discouraging either side in advance.

The tips and strategies in this document should be applied with judgment and expertise. Procurement specialists within your organization have the knowledge and experience to determine what constitutes a realistic and successful balance between:

* clear and sufficient functional requirements;
* room for innovation and flexibility;
* promoting open source where possible; and
* avoiding unnecessary restrictions that discourage suppliers.

These recommendations show that it is possible to create a level playing field. This way, a single procurement can appeal to both closed and open ecosystems while keeping the process transparent, fair, and effective—within the framework of the Dutch Public Procurement Act and in the practical language of procurement professionals.

# Contributors

Thanks to everyone mentioned by name here, as well as all the contributors who wish to remain anonymous.

* Maurice Hendriks (Main author; Ministerie van Volksgezondheid, Welzijn en Sport)
* Mike Gifford (CivicAction)

---

This text is available under the CC-BY-4.0 \
[](https://hackmd.io/Fhj24cTRRm2FKjhuUyN3Xg)

>[!Note] License
>
> {%hackmd NM4kkB6ESKuQ1pIJFKmYzA %}