OCDS 1.2: We want to hear your proposals

The Open Contracting Data Standard (OCDS), is a free, non-proprietary, open data standard for public contracting, implemented by over 30 governments around the world. It is the only international, open standard for publishing information related to the planning, procurement, and implementation of public contracts, and it has been endorsed by the G20, the G7 and major international organizations.

Today, we kick off the development of the next minor release of the Open Contracting Data Standard, OCDS 1.2.

How did we get here?

The OCDS 1.0 release candidate was published in November 2014, after a year-long rapid development process. It allowed governments to publish information about 130 common concepts in public contracting in a standardized format.

OCDS 1.1 was published in May 2017, after another year-long process. It added a way for governments to add additional concepts to their data (“extensions”), reduced the repetition of organizational details, and added or updated common concepts, bringing the total to 160.

What is a “minor release”?

A release is a new version of the standard that updates the rules to follow in order to be compliant with that version.

A minor release is backwards compatible. This means that any data that is compliant with OCDS 1.0 is still compliant with OCDS 1.1 (and 1.2 and onward). If a new rule were to, for example, require the publication of a specific concept in OCDS 1.2, then any data from OCDS 1.0 or 1.1 that omitted that concept would no longer be compliant. As such, the changes that can be considered for a minor release are constrained. (A major release is backwards incompatible and without constraints.)

That said, there is room to shift the constraints in a minor release. For example, OCDS requires the use of its terms for the concepts it covers. For instance, the list of submitters to a contracting process must be labelled using the term ‘tenderers’ (and not another term like ‘participants’) – even if that contracting process is a design contest for which ‘participants’ is a more appropriate term than ‘tenderers’. It would be backwards incompatible to change ‘tenderers’ to a generic term like ‘submitters’, because data that uses ‘tenderers’ from OCDS 1.0 would fail the requirement to use ‘submitters’ in OCDS 1.2. To get around this constraint, OCDS has a deprecation policy, according to which the ‘tenderers’ term can be discouraged (but not removed) in a new version.

The deprecation policy should be used sparingly, because if different datasets are frequently using different terms for the same concept, interoperability isn’t maximized, which is the purpose of standardization.

Where are we going?

Since 2017, the number of implementations of OCDS has doubled, through which the OCDS community has learned a lot about what works and what doesn’t. This is reflected in the challenges and ideas for improvements that OCP, publishers and users have reported to the standard’s GitHub page. Many reported issues have been addressed without changing OCDS’ rules, through patch releases like OCDS 1.1.4 in 2019 and OCDS 1.1.5 in 2020. Another 40 issues can be resolved without a new release, simply by updating the Guidance section of the OCDS documentation.

However, about 90 issues require rules changes – and therefore a minor release.

The major themes among the reported issues are:

• Semantic issues. Many terms in OCDS were defined from the perspective of single-stage procurement procedures. However, OCDS is intended to support two-stage procurement procedures, as well as other processes like design contests, public-private partnerships, concessions, leases, sales, and so on. The definitions of many terms need to be refined so that their meaning is clear in different contexts.
• New validations. It is backwards incompatible to add validations, like requiring the publication of a concept. OCDS’ validations are described in schema files. We could add ‘strict’ versions of the schema files, to give publishers the option to opt-in to new validations, and thereby improve their data quality.
• Add or deprecate fields and codes. There are several concepts to consider adding to OCDS that are common to multiple jurisdictions. There are also a few concepts to consider deprecating, due to their being unclear or insufficiently distinct.
• Update extensions. The bids, enquiries, location, lots and participation fees extensions are versioned with the standard, and several improvements to these extensions are being considered – including whether to merge lots into OCDS.
• Various proposals, including whether to change how OCDS data is packaged or how multilingual content is published.

The issues can be explored thematically via this board.

How to contribute?

The development of OCDS 1.2 follows the governance process.

The first step is to propose new issues to address by 28 October. All existing issues that can be resolved in a minor release are already collected into the 1.2.0 milestone. If there is something outside that list that you would like to see changed, please create an issue on GitHub. If you are new to GitHub, you can watch a recording of our introduction to GitHub, review the slides, or use this handout. 

After that first deadline, OCP will update the 1.2.0 milestone with new issues. There will be another two-week window during which anyone can discuss whether to include issues that were left out, or remove issues that were added in. Then, over many months, solutions to the issues will be prepared through GitHub discussions and community calls. To get updates about the process, please subscribe to the standard-discuss mailing list.

We look forward to active participation of the OCDS community throughout this process, to ensure the OCDS remains the best means of disclosing public contracting data.