---
url: 'https://dri.es/the-60-second-procurement-test'
title: 'The 60-second procurement test'
author:
  name: 'Dries Buytaert'
  url: 'https://dri.es/about'
date: '2026-09-09T14:45:17-04:00'
license: 'https://creativecommons.org/licenses/by/4.0/'
type: blog
summary: 'Anyone paying for Open Source work should be able to check whether a vendor contributes. Open Source projects should take responsibility for making that easy by publishing contribution records.'
tags:
  - 'Open Source'
  - 'Open Source sustainability'
  - Policy
  - Drupal
published: true
featured: false
id: 6326
---

# The 60-second procurement test

Open Source projects have spent decades asking companies to contribute. Projects should also give buyers the information they need to reward the companies that do.

Any Open Source project with a commercial or institutional funding ecosystem should publish an official contribution record: who contributes, how much and over what period, what kind of work they do, which parts of the project they work on, and, where disclosed, who paid for the work.

The test for a good record is simple. A buyer should be able to answer three questions in about a minute: does this vendor contribute at all, how much do they contribute compared to other vendors, and do they work on the parts of the project I care about?

Contribution does not prove that a vendor can deliver. It is one procurement factor alongside delivery capability, expertise, and price. It matters because some buyers want the money they already spend on Open Source services to help maintain the software they depend on.

Vendors that pay people to do that work carry costs that others avoid, and some of those costs may appear in their rates. A price comparison that ignores those costs can put contributing vendors at a disadvantage. I've argued that [procurement should score contribution alongside price](https://dri.es/funding-open-source-like-public-infrastructure). APELL, the European Open Source Software Business Association, has also asked the EU to [consider a provider's record of Open Source contribution](https://apell.info/wp-content/uploads/2025/07/2025-07-03_Feedback%20APELL_Cloud%20and%20AI%20Development%20Act%20consultation.pdf).

## Vendor claims are hard to verify and compare

Say you need a vendor for your Drupal site, your Kubernetes cluster, or whatever Open Source software you use, and two firms bid. Both say they're deeply involved in the project, and both might be telling the truth by their own definition of "involved".

Without a project record, verifying those claims often means reconstructing each vendor's contribution history yourself.

The code repository seems like the obvious place to start, but even counting commits by vendor is not simple. A project has to connect individual contributors to the organizations that employed or funded their work, and those relationships can change over time.

More importantly, Open Source contribution can include documentation, support, event organization, governance work, promotion, and more. Much of that work happens outside the code repository or isn't recorded in a form a buyer can easily interpret.

## Projects decide which contributions matter

Drupal has tracked contribution credits since 2015, following [a method I proposed in 2014](https://dri.es/a-method-for-giving-credit-to-organizations-that-contribute-code-to-open-source) and now [governed by the Drupal Association](https://www.drupal.org/contribution-credit). Its system records more than code and gives credit not only to individual contributors, but also to the organizations and customers that fund their work.

Not every contribution counts the same. A contribution to Drupal Core or a strategic initiative earns more credit than one to a module that few sites use, and work on contributed projects counts for more when more sites depend on them.

Raw contribution data does not tell buyers which work matters most to the project. The project has the context to decide what advances its priorities and how different contributions should be weighted. Its record should publish those rules, link to the underlying contributions, and explain how mistakes or disputes are corrected. Buyers can then decide how much that record matters for a particular purchase.

Drupal has a strong foundation, and credits feed the [Drupal.org marketplace](https://www.drupal.org/drupal-services) where buyers compare agencies, but I'm not sure we could answer all three questions in sixty seconds today. We still have work to do to make the record easier to find, understand, and compare.

## Projects can start with a simple record

Not every project needs a system as elaborate as Drupal's. A small project could begin with a short list: who its recognized organizational contributors are and what they worked on. A text file in the official repository can be enough for a first version.

More complex ecosystems may need separate categories or weighted comparisons. Whatever form it takes, the record has to be easy to find and quick to use. 

So if you maintain an Open Source project with a commercial or institutional funding ecosystem, start publishing a contribution record and improve it over time. If you buy services built on Open Source, ask for the project's contribution record. Decide at the start how contribution should count in your purchasing decision, then check bidder claims against the record. If you fund Open Source, use the record to find contributors working on the parts of the project you want to support.

Where buyers can consider contribution, I expect projects with clear records to see more commercial opportunities go to their maintainers than projects that rely on appeals alone.

*Special thanks to [Henry Poole](https://en.wikipedia.org/wiki/Henry_Poole_\(technologist\)) for his contributions to this blog post, and to [Sachiko Muto](https://www.linkedin.com/in/sachikomuto/), [Tiffany Farriss](https://www.drupal.org/u/farriss), [Tim Lehnen](https://www.drupal.org/u/hestenet) and [Amandine Le Pape](https://www.linkedin.com/in/amandinelepape/) for their review.*