Hi all,
The DIN SPEC 3105 is now officially out. Woop woop! 
A lot has been done within the two years that have passed since the first message in this thread. Let me give a short summary of what happened and give an overview of the results (@Moe correct me if I am wrong!).
Background
The starting point of the DIN SPEC 3105 initiative is that the Open Source Hardware Definition gathered by the OSHWA is a great thing, BUT it is quite vague when it comes to define what the “source” of hardware is. Leaning upon the Open Source Definition, it sets quite explicite requirements in terms of hardware documentation licensing, but it says little about what should be included in the documentation. OSHWA’s best practices deliver some insights, but these are recommendations and are very generic. So the idea was to extend the OSHWA definition into a comprehensive OSH definition that sets concrete, clear, verifiable requirements in terms of licensing AND documentation contents.
The project started around two years ago led by @Moe and some GOSH community members involved in the working group (thanks @access2perspectives cessary funding so we can have an official standardisation process at the German Standardisation Organisation. (Why the German Standardisation Organisation? Just a matter of opportunities and contacts. I guess we could have done it with any other standardisation organisation.) It took approx. one year to come to a first draft and one another year to make sure this draft complies with the formal requirements of the German Standardisation Organisation. Looking back at these two years, I have the feeling it was easier to find consensus within the working group and with the OSH community than with the formal requirements of the DIN. Which is a good thing since it means we agreed on the contents!
The working group was composed of: Felix Arndt (Open Source Imaging and Fair GmbH), Tobias Burkert, Lukas Schattenhofer, Mehera Hassan, Robert Mies (TU Berlin), Jerry de Vos (Precious Plastic), Fabian Flüchter (IP Center Bucerius Law School), Martin Häuer, Dietrich Jäger, Timm Wille (Open Source Ecology Germany e.V.), Brynmor John (Field Ready), Manuel Moritz, Tobias Redlich (Helmut Schmidt University), Christian Schmidt-Gütter (Cradle to Cradle e.V.), Emilio Velis (Appropedia Foundation), Joost van Well (Cleopa GmbH), Diderik van Wingerden (think.innovation), Tobias Wenzel (Journal of Open Hardware), Lukas Winter (Physikalisch Technische Bundesanstalt), Lars Zimmermann (Mifactori – Open Circularity) and myself. We had also contacts with a lot of other members of the broad OSH community and gathered quite a lot of feedback, including from OSHWA members.
What is the result of this working group?
A standard in two parts:
- DIN SPEC 3105-1:2020-07, Open Source Hardware - Part 1: Requirements for Technical Documentation. This document delivers an unambiguous definition of the term Open Source Hardware based on objective and enforceable criteria.
- DIN SPEC 3105-2:2020-07, Open Source Hardware - Part 2: Community-Based Assessment. This document defines requirements for an assessment procedure for OSH products based on reviews by OSH community members, emulating the model of peer-review used in scientific publishing.
Where to find it?
- On the official DIN webshop. You can download there the official DIN documents free of charge, however they require a registration (not cool). Here are the links:
- DIN SPEC 3105-1:2020-07
- DIN SPEC 3105-2:2020-07
- On the GitLab repo of the working group. Here it is completely open, no charge, no registration. You can find there the “preprints” of the documents, so to say. That is: same contents, different layout. Here are the links:
- DIN_SPEC_3105-1.md, alternatively as PDF here
- DIN_SPEC_3105-2.md, alternatively as PDF here
What’s new in there?
DIN SPEC 3105 Part 1
Here I would just shamelessely copy and past a chunck of a paper @MakerTobey , @jcm80 and @Moe wrote for the Journal of Open Hardware to report about current standardisation initiatives in OSH (still under review, preprint available here):
[The DIN SPEC 3105-1] "breaks down the requirement made by the OSHWA Definition 1.0 to enable “anyone [to] study, modify, distribute, make, and sell the design or hardware” into clear, actionable ways to meet that requirement. Therewith, it defines four “Rights of Open Source” transposing the “four essential freedoms” stated in the Free Software Definition (Free Software Foundation 2019) and links them with concrete requirements in terms of documentation content. These rights are the right to study, to modify, to make, and to distribute.
It acknowledges that OSH is not only a matter of licensing but also a matter of documentation contents. It differentiates between granting the four rights of open source and enabling others to effectively exercise these rights.
It acknowledges that the content of the documentation to be shared depends on the hardware technologies embedded in the product under consideration (e.g. electronic hardware). To account for these dependencies, the specification only dictates generic requirements in terms of documentation contents. These contents are in turn specified by so-called “Technology-specific Documentation Criteria” which are specific for each technology.
It acknowledges that the content of the documentation also depends on the audience targeted by the documentation. It is not practicable to allow “anyone [to] study, modify, distribute, make, and sell the design or hardware” since not everyone has the same capacity to read and make use of product documentation. Instead, documentation is required to address a defined group of recipients. The default is that documentation must provide no less information than what specialists in the fields of this technology would require to exercise the four rights of open source hardware. This allows setting a set of practical minimal expectations in terms of documentation format and completeness that can be outperformed by documenters.
It adopts a product life cycle perspective, considering that “making” a product is not only about manufacturing it, it is also about using, maintaining, updating and processing it at end-of-life. It defines documentation as information allowing to operate all activities belonging to the product life cycle, from raw material extraction to end-of-life. Therewith, it drops the arbitrary and artificial barrier made by previous standards between production and the rest of the life cycle."
About the “Technology-specific Documentation Criteria”-thing: the idea is that not all “hardware” is equal when it comes to documentation. For example, the documents you need to reproduce 3D-printed gimmick are not the same you need to reproduce a full-sized humanoid robot. In the first case, it does not make sense to ask for a BoM or assembly instructions, but these documents may be essential in the second case. The DIN SPEC 3105 Part 1 takes account of this and defines a generic frame that is complemented by technology specific documentation criteria (TSDC). In the current version of the standard, the TSDCs are pretty light touch in order to facilitate adoption and not to put too much burden on the autors/documenters. Later, when we will have more experience in using the standard, we will be able to narrow down these criteria.
DIN SPEC 3105 Part 2
The idea of the second part is to create a “peer-certification” process allowing the OSH community to certify hardware instead of paying horrendous amounts of money to intransparent third party certification agencies. This process copies open peer-review processes at play in some scientific journals (and what we are working on for the Journal of Open Hardware): all reviews are public and included in the published material. That way, it is very difficuly to cheat and there is a greater chance that the assessment represents on average the view of the community.
Where we stand
The cool thing about this standard is that it is open source itself. It is the first ever standard published by DIN under a CC-BY-SA 4.0 license. This was required to enable a new kind of open standardisation process: from now on, any new version of this standard will be established in the community instead of within a closed working group as usual in standardisation bodies. I think @Moe and other people who dealt with DIN in this project can be especially proud to have made a national standardisation body revise their practices and working on new open processes they may further develop in the future.
The governance guidelines for participating in the further development of the standard itself and the technology specific documentation criteria are respectively here and here. That is: if you think something has to be improved in the current versions, flag an issue in the GitLab repo, join the discussions, fork and edit, the scene is yours!
To conclude
There would be a lot to say about this initiative and even more about how to use it. I tried to say a lot in condensed form and I guess that some parts will not be clear. So maybe I just leave it here and wait for the questions 
Maybe @Moe and friends can also tell us a bit more about future steps and associated projects where this standard will be applied?