Of course, contribution does not prove that a vendor can deliver. It is one procurement factor alongside delivery capability, expertise, and price.
Without a project record, verifying those claims often means reconstructing each vendor’s contribution history yourself.
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”.
§Vendor claims are hard to verify and compare
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.
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 complex ecosystems may need to categorize vendors, support searches by location, or weight different kinds of contribution. Whatever form it takes, the record has to be easy to find and quick to use.
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?
§Projects should decide which contributions matter
Drupal has tracked contribution credits since 2015, following a method I proposed in 2014 and now governed by the Drupal Association. 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.
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.
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.
Not every project needs a system as elaborate as Drupal’s. For a small project, a text file in the official repository listing its recognized organizational contributors and what they worked on can be enough for a first version.
§Projects can start with a simple record
I believe 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.
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.
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.
Special thanks to Henry Poole for his contributions to this blog post, and to Sachiko Muto, Tiffany Farriss, Tim Lehnen and Amandine Le Pape for their review.
Where buyers and funders 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.
In Drupal, contribution credits feed into the Drupal.org marketplace where buyers can look up agencies and compare them. While we have a strong foundation, we still have work to do to make the record easier to find, understand, and compare.
Finally, if you fund Open Source, use the record to find contributors working on the parts of the project you want to support.
