De jure standardisation in the digital era: trying to catch bees with a lasso
Over the past century, de jure standardisation, established by national and international standards bodies, has become a cornerstone of modern industrial societies. These organisations provide a robust and structured framework for developing representative consensus – meaning that technical standards reflect a broadly agreed-upon understanding across all relevant interested groups, capturing the state of the art in a formal and reliable manner.
Due to their representativeness (and the respective mandate),de jure standards can be directly referenced in legislation, thereby becoming part of public regulation.Consensus within this framework creates an environment where all actors are mutually dependent, preventing any single party from dominating the process. This balance is further reinforced by the involvement and information of the general public.
On a European level the Comité Européen de Normalisation (CEN), the Comité Européen de Normalisation Électrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI) provide a solid infrastructure to converge de jure standards across all member states.
However, this standardisation model is also characterised by long development cycles – typically measured in years – and a uniform approach to format and documentation. Since the advent of the information and communication technology (ICT) and information technology (IT) sectors, which operate under much faster innovation cycles, standardisation in these domains has increasingly moved away from standards bodies and toward open source communities.
Open standards: hives making their own rules
Today, there is strong evidence that open source constitutes the dominant development model in the software domain.The market shares of open source software (OSS) are typically estimated between 70 % and 90 %, and with indications of exponential growth extending back more than three decades.
These communities operate on implementation-first principles: technical solutions are immediately applied, iteratively improved, and openly shared. Here, standardisation occurs not by consensus ahead of implementation but as an emergent property of real-world use, remixing, and adoption. This principle has been referred to as a meritocratic process in which actors continuously iterate on existing designs to produce “best-of-breed” solutions for their own use cases: The value of a solution is judged primarily by its feasibility and effectiveness and influence is earned through contribution and technical merit.
Within this model, there is a strong incentive to integrate design changes as close to their original source as possible: In the common analogy of a river, feedback, bug fixes, or feature requests originating from downstream users – i.e. implementers of a solution – travel upstream to the community of the respective component.
As a result of the emergence of decentralised inclusive decision-making through open source communities, de jure standards bodies are becoming increasingly redundant in these sectors.However, because open source ecosystems typically focus on solutions close to or at the product level, they do not inherently compete with them. Rather, they offer a complementary approach to technical standardisation. Several successful collaboration schemes between standards bodies and open source projects exist, while greater policy alignment would further enhance these efforts.
In part, these open source ecosystems are supported and moderated by dedicated standard-setting organisations (SSOs) offering a variety of (mostly) consortium-based processes. These SSOs adopt organisational structures similar to de jure standards bodies but do not require representative consensus, which also allows them to move more quickly and adaptively.However, this may come at the expense of a broad underrepresentation of essential stakeholder groups – for instance, users in the case of IT and ICT standardisation. Stakeholders are free to choose the SSO whose policies best reflect their interests and circumstances, a practice sometimes referred to as “forum shopping.”
Limits of open standards: the hive should not govern the garden
The power-balance within these open source ecosystems – and so also the possibility to govern parts of it with industry consortia – mainly relies on two key factors:
1. The freedoms granted by open source licenses, which give anyone the right to distribute modifications and remixes(forks);
2. a low cost of change, which enables as many communities as possible to put these forks into circulation, as software can be copied, modified, and distributed globally, almost instantly, and at negligible costs.
In contrast, for high-cost-of-change technologies – such as most hardware – these open source meritocratic mechanisms are unlikely to generate equivalent standardisation effects within the limited timeframe of a typical product life cycle.
Furthermore, consortium-based standardisation in such fields is potentially problematic, as the high barriers for retroactive adjustments make these efforts more susceptible to dominance by individual actors – such as those observed, for example, at the Internet Engineering Task Force.Consequently, de jure standardisation remains the default method for ensuring representation and broad legitimacy in high-cost-of-change sectors.
Open source hardware: a beast of two worlds
Open source hardware (OSH) falls into the crack between these two worlds. Similar to software, OSH development is primarily community-driven, taking place in online environments that enable large-scale collaboration under the absence of restrictive intellectual property (IP) policies.
OSH also bears the potential to achieve faster and more cost-efficient development cycles compared to proprietary hardware (e.g. ranging around 90 % cost savings in the domain of lab equipment), partly due to network effects and strong participatory elements, while diversifying supply chains and thereby creating resilient technical solutions that can be sourced locally. The effects of a low barrier to entry can be seen in OSS development practices, where early-stage involvement of users often results in feedback cycles that are “an order of magnitude faster than most commercial software projects.”
However, these effects remain considerably more limited in the case of hardware. As with software, the timelines of de jure standardisation processes are misaligned with the pace of OSH development. Furthermore, the intentionally abstract nature of such standards precludes complex product-level specifications, while the established workflows and IP regimes of standards bodies typically do not align with open source principles.
At the same time, practices from the OSS domain cannot be directly transferred to OSH due to the structural misalignments outlined above, compounded by the fact that OSH remains primarily driven by volunteer- or research-led communities, with industry participation and market capitalisation still significantly lower than in the OSS domain.
Furthermore, just as definitions of open standards vary widely, so too do the procedural rules for standardisation within OSS communities. Consequently, it remains unclear which procedures of open standardisation would be well-suited for the context of OSH. Although standardisation practices within the OSH community do exist – e.g. concerning technical documentation and metadata, as well as, to a limited extent, on the product level – these efforts remain isolated.
Collaborations with standards bodies and with SSOs, such as CERN White Rabbit with the Institute of Electrical and Electronics Engineers (IEEE) or RISC-V with the Linux Foundation, provide further examples. However, there are as yet no dedicated SSOs or standardisation methods specifically tailored to the needs of OSH communities. Moreover, no systematic research has been conducted on the specific requirements for such methods.
Representative open standards for hardware and beyond
One of the projects at the Just Transition Center (JTC) of the Martin-Luther-Universität HalleWittenberg aims to contribute to closing this gap without superseding existing infrastructures: The objective there is to develop an understanding of the needs of OSH communities in order to enable their effective initiation and management of, as well as participation in standardisation projects, while at the same time complementing existing schemes and fostering collaboration with established institutions and actors – principally de jure standards bodies and SSOs from the software domain.
The standardisation methods deducted from the findings, will be piloted and validated in close collaboration with OSH communities. However, OSH only stands as an example for high-cost-of-change issues that cannot afford the current iteration cycles of de jure standardisation. The author of this article suspects that this new standardisation method might be transferable to other domains, that operate at the level of an imminent implementation, while relying on a representative consensus, for example: open reference technologies for public infrastructures or possibly even administrative and decision-making processes.
A hybrid approach, combining open source solutions at the implementation level with a structured and representative integration into overarching standards, would enable effective early stakeholder involvement in piloting new regulations, while simultaneously preserving the free exchange of practical experience that supports and accelerates consensus-based standardisation. If the topic outlined in this article resonates with the reader, they are warmly invited to reach out to the JTC project or the author directly. We look forward to connecting, exchanging ideas, and — in the spirit of open source — collaborating across disciplines to advance the development of open standards.
About the Author
Martin Häuer is the Scientific Head for open standards (JTC-C1) at Martin-Luther-Universitaet Halle-Wittenberg. He is deeply engaged in the open source hardware ecosystem, mainly focusing on project coordination, documentation and governance. Martin has been active in several communities, including Open Source Ecology Germany, that he chaired for three years and where he initiated and led the development of DIN SPEC 3105 and maintained the OKH metadata standard.
1.DIN EN 45020, 1.5
2.DIN 820-1, 5.1, “Normungsvertrag”; “New Legislative Framework - European Commission.
3.DIN 820-1,5.3
4.Ibid., 7.4.
5.Böhm and Eisape, “Standard Setting Organizations and Open Source Communities.”
6.Musseau et al., “Is Open Source Eating the World’s Software?”; Black Duck, Open Source Security & Risk Analysis Report
7.Deshpande and Riehle, “The Total Growth of Open Source.”
8.Böhm and Eisape, “Standard Setting Organisations and Open Source Communities.”
9.Whitehurst, The open organisation
10.Böhm and Eisape, “Standard Setting Organizations and Open Source Communities
11.Blind, Thumm, and Böhm, The relationship between open source software and standard setting.12.De Vries, Verheul, and Willemse, “Stakeholder Identification in IT Standardization Processes.13.Lerner and Tirole, “A Model of Forum Shopping.”
14.Böhm and Eisape, “Standard Setting Organizations and Open Source Communities.”
15.Ibid.; Blind, Thumm, and Böhm, The relationship between open source software and standard setting.
16.Lerner and Tirole, “A Model of Forum Shopping.”
Simcoe, “Standard Setting Committees.”
17.Böhm and Eisape, “Standard Setting Organizations and Open Source Communities.”
18.Moritz, Redlich, and Wulfsberg, “Best Practices and Pitfalls in Open Source Hardware.
19.Heikkinen et al., “Towards National Policy for Open Source Hardware Research.”
20.Weber, The Success of Open Source
21.Even though Weber’s study is over twenty years old, the underlying dynamics have likely remained similar
22.“DIN 820 Beiblatt 3,” 5.1.
23.Blind, Thumm, and Böhm, The relationship between open source software and standard setting
24.Díaz-Marta and Ferrandis, “Open Standards and Open Source”; Krechmer, “Open Standards Requirements.
25.Bonvoisin et al., “Standardisation of Practices in Open Source Hardware.
26.For instance the Freespireco project in the domain of open-source ventilators; https://github.com/PubInv/freespireco accessed 2025-09-10T19:27:05+02:00
27.Bonvoisin et al., “Standardisation of Practices in Open Source Hardware.
28.Gamalielsson et al., “On Engagement with Open Source Software, Open Source Hardware, and Standard Setting.”
29.https://www.linuxfoundation.org/press/press-release/the-linux-foundation-and-risc-v-foundation-announcejoint-collaboration-to-enable-a-new-era-of-open-architecture