Getting started

This section provides an understanding of the initial steps to get started with open standard development

Understand the ecosystem

Understanding the ecosystem your standard will operate in can help establish what stakeholders value. Ecosystem maps help you understand where and how value is created, and what can be done to support value creation.‌

Ecosystem maps help identify players, environmental conditions and the relationships between them. When you have mapped the ecosystem, you can establish where your open standard fits and the value it can provide. By providing value to stakeholders, your open standard is more likely to be adopted and create impact.

Ensure that the players you identify include a wide variety of people and organisations who will use or be affected by the standard or its outputs, including data and models. Stakeholders can include:

Solve clearly defined problems

In our research, ‘User experiences of open standards for data’, we found that a successful standard is a useful standard. The people we interviewed suggested that a successful open standard for data focuses on solving a particular problem or need. This is supported by our research, ‘Exploring the development and impact of open standards for data’, where we found active open standards with thriving communities focused on solving particular problems.

Understanding the ecosystem is one way to ensure that the problem or need exists and is clearly articulated. Using clear and inclusive language is also important when engaging with people and organisations. To ensure you are solving the right problem, everyone should understand what is being discussed. This means agreeing on concepts, meaning and definitions and avoiding jargon.

‌Google’s General Transit Feed Specification (GTFS), for example, focuses on making it easy to share and use public transit information, while the Open Contracting Data Standard focuses on disclosing public procurement information for the public good.‌

Work with other standards

Open standards are part of an ecosystem, which means there are likely to be competing and complementary standards already in use. Where possible, use or extend an existing open standard rather than create a new one. If you do decide to create a new open standard, ensure it works with or is based on existing standards. This not only makes it interoperable, but also increases the value of the standard to stakeholders.

An open standard can work with other standards by:

  • ‌using an established vocabulary rather than creating new language, identifiers or codes. The International Aid Transparency Initiative (IATI) open standard for aid transparency re-uses Organisation Registration Agency codes from a number of authoritative and established registrars including the UK’s Companies House

  • adopting supported open formats like CSV or JSON instead of proprietary formats — the Fiscal Data Package standard for government budgets uses the JSON format for packages and plain text CSV format for data files

  • using models developed to map and understand ecosystems and information flow — the Open311 collaborative model for civic issue tracking has been adapted by City of Chicago, with the help of Code for America, to meet the city’s needs

  • reusing established standards as building blocks for a new standard — the 360Giving standard for charitable grant making is based on schemas from schema.org, the collaborative standard for structured data on the internet

Open standards can also treat other standards as ways to extend the features available to stakeholders. For example, governments disclose public procurement information such as tenders, awards and contracts. They also disclose budgets and spending. Including all of this information in a single standard would make it verbose and would dilute its focus.

‌Instead, governments can use the Open Contracting Data Standard to disclose public procurement and the Fiscal Data Package standard to disclose budgets. Both disclosures can be linked using reference numbers allowing developers to easily link procurement and budgets.

Deliver a robust product

An emerging theme from our user research was the robustness of open standards: open standards developed collaboratively with a variety of people and organisations and tested to ensure they are fit for purpose.

‌Including a wide variety of stakeholders ensures the open standard is not focused too narrowly and that it provides a needed solution. Testing the standard and outputs, including data and models, ensures that the standard works in real life, assumptions are clarified, and errors are spotted early. A robust standard does not need to be verbose; it can focus on the core and critical features needed for adoption and use. This allows the standard to launch, be adopted by people and organisations and then evolve with their needs.

Last updated