DIN SPEC 3105 Explained
By Jérémy Bonvoisin, University of Bath
In the past 18 months I had the pleasure to be part of a great adventure: establishing a new standard refining the contours of what we mean with “Open Source Hardware”. This standard, DIN SPEC 3105, sets a new milestone in the efforts of the open source hardware community to build shared practices and to chart a common identity. In this article, I summarize the main lines of the standard, focusing on the essence without going too much into technical detail. I also explain why I believe this standard is by design an opportunity for the open source hardware community rather than an annoying set of imposed rules. Finally, I discuss some of the challenges the dissemination of this standard will face and mention a few initiatives attempting to tackle them.
What is DIN SPEC 3105 about?
DIN SPEC 3105 intends to make it clearer for everybody what open source hardware is. For end-users to make the difference between the “real” and the “fake”. For developers to know what information they need to disclose to label their hardware as open source. For policy makers to have a clear reference endorsed by an official standardisation body.
For this, DIN SPEC 3105 does two things. First, it provides an explicit and enforceable definition of the term “open source hardware”. This is done in Part 1, entitled “Requirements for technical documentation”. Second, it defines a new kind of community-based assessment process. This is done in Part 2, entitled “Community-based assessment”.
Part 1 is about defining what makes a product an open source hardware product. In other words, it sets requirements that must be fulfilled by the documentation of a piece of hardware so it is legitimate to label it as open source hardware. To do so, DIN SPEC 3105–1 builds upon the generally acknowledged “Open Source Hardware Definition 1.0” hosted by the Open Source Hardware Association (OSHWA). This document defines precise licensing terms under which hardware devices and their documentation should be released to align with the ethos of the open source movement, as coined in the Open Source Definition. DIN SPEC 3105–1 adds a new layer by setting requirements in terms of documentation contents. It defines the minimal set of information developers should share so “anyone can study, modify, distribute, make, and sell” their hardware, as required by the OSHWA-hosted definition. In that sense, DIN SPEC 3105–1 is an interpretation of the OSHWA-hosted definition that intends to deliver more practical details. Altogether, these documents make it clear 1) what information has to be shared and 2) under which licensing terms, so a piece of hardware qualifies as open source hardware.
Part 2 is about compliance assessment. It defines an innovative community-based assessment procedure that offers a middle-way between self-assessment and third-party certification — the two conventional ways of stating product compliance. On one side, self-assessment is flexible and inexpensive for originators. But this is a rather weak form of assessment that works more for established and legally enforceable concepts than for emerging concepts such as open source hardware. It is practical, but does not generate high levels of trust. On the other side, third-party assessment is a solid process ensuring a higher objectivity. But is associated with high costs and potentially vendor lock-ins. It is trusted, but impractical in the context of open source hardware where projects rely on voluntary contributions. DIN SPEC 3105–2 defines a third way that mimics the peer-review process at play in scientific publishing: assessments are not granted by a central entity but by the community itself. Hardware originators can submit their hardware documentation to a neutral conformity assessment body that hosts the assessment process, looks for community members to perform the reviews, collects the reviews and makes them publicly available online, and, based on the reviews, issues an attestation. Reasons for granting an attestation are transparent, claims are verified and therefore trusted, and nobody needs to pay anything other than the time they invest in the assessment process.
More than a standard: An un-standard
While standards generally “set in stone” already long-established practices, DIN SPEC 3105 intends to find the right balance between rigour and flexibility. Instead of imposing requirements in a top-down approach, it is meant as a tool for the open source hardware community to shape its own expectations. This is done in two ways.
Refining-by-doing: Building technology-specific documentation criteria
First, DIN SPEC 3105–1 provides a general framework that needs to be refined in practice. A major innovation of this document is to acknowledge that hardware documentation content depends on the technologies embedded in the product under consideration. For example, the documentation required to replicate a PCB differs from those required to replicate a 3D-printed figurine. For a PCB, you need layouts and schematics and eventually a bill of materials (BoM). For the figurine you need some CAD model. BoM and schematics are irrelevant for the figurine, so is the CAD model for the PCB. Consequently, it is not possible to define hardware documentation in detail and for all products. Documentation contents depend on the technology embedded in the hardware product and eventually on other criteria such as product complexity. In order to account for this, DIN SPEC 3105 only provides very generic requirements in terms of documentation contents, but these generic requirements are in turn expected to be narrowed down in so-called “Technology-specific Documentation Criteria”. These are appendices to the standard that can be refined little by little throughout the process of assessing products and learning what can be practically expected from originators. The set of technology-specific documentation criteria delivered with the first published version of DIN SPEC 3105 is purposefully a light touch, in order to avoid putting unrealistic burden on open source hardware originators. These requirements are intended to grow in maturity through discussions arising in the assessment of hardware devices. The more devices assessed, the more lessons learned could flow into the definition of stable technology-specific documentation criteria.
Participative revision process thanks to an open source standard
Second, DIN SPEC 3105 is the first standard *ever* to be hosted by a national standardisation organisation (in this case DIN, Deutsche Institut für Normung) under an open source license. The first implication of this is that the standard can be accessed, copied and distributed free of charge. While the publishing branch of DIN (Beuth Verlag) requires you to sign in to download the official documents formatted into DIN’s IP-protected templates and graphical identity, nothing prevents anybody from putting the content of these documents online. The second and even more far-reaching implication is that further versions of the standard can be developed in an open process where anybody can participate. In that sense, DIN SPEC 3105 sets a unique precedent showing that standardisation does not have to happen behind closed doors as it generally does, but can be undertaken publicly, online, and in a way that can involve any interested contributor. This is what the community repository of the DIN SPEC 3105 working group in GitLab is already trying to achieve. From there, anyone can freely access the first release of the standard and the current version edited by the community, together with accompanying documents. Anybody wanting to help improve these documents and to contribute to a new version can visit the contribution guide, participate in discussions around ongoing issues, flag a new issue, or clone the repository and make a merge request.
Outlook: From theory to practice
DIN SPEC 3105 suggests, in many ways, entering uncharted territories. How far it will be used in practice depends on multiple factors. Is it well aligned with the interests of open source hardware developers and their willingness to invest time in providing standard-compliant documentation? Will the expected iterative refinement of the technology-specific documentation criteria prove to be practicable? Will the implementations of the theoretically elegant but unconventional conformity assessment model meet the ideals of fairness, stability and transparency the authors of the standards tried to achieve?
There are many ways the community can involve and make this standard becomes more than a piece of writing. One of them, Open Source Ecology Germany, is currently building the first conformity assessment body hosting the community-based assessment process. This is done as part of the oho.wiki project supported by the EU-funded project OpenNext. They are setting up the necessary infrastructure and are recruiting volunteers for a first assessment wave. If you are a hardware developer and would like to get your product attested, or if you are interested in assessing hardware products as a reviewer, don’t hesitate to contact them at email@example.com. This initiative also builds a bridge with another practical issue in open source hardware: finding existing designs. They are building a search engine based on the open hardware metadata standard Open Know-how Manifest Specification 1.0. The objective here is to allow finding, filtering and cross-linking hardware documentation (e.g. answer queries like “find all ongoing and well documented COVID-19 research connected with open source ventilator designs”). If you want to take part in the development of this infrastructure, get in touch with firstname.lastname@example.org or visit their repo directly.
Regardless of these projects, DIN SPEC 3105 already formalises some of the implicit principles at play in the open source hardware community and makes practical propositions for some open questions. Doing so, it contributes to the emergence of shared practices and the establishment of a visible and trustable identity. More, it does this in a way that aligns with the ethos of transparency and participation that is key to the open source movement.
- The community version of both DIN SPEC 3105 Part 1 and Part 2 can be consulted free of charge on the community repository of the DIN SPEC 3105 working group in GitLab. The officially published versions from DIN can be downloaded by registered users free of charge here and here.
- The FAQ in the GitLab repository of the DIN SPEC 3105 working group provides more information about the initiative, the people behind it, the governance of the project, the relations with other standards, and many other topics.
- More detail about the principles adopted in the standard and the major innovations it brings to light are provided in this article published in the Journal of Open Hardware.