Open Hardware Distribution & Documentation Working Group: Defining Priorities
This is the fourth post of the series of the Open Hardware Distribution and Documentation Working Group (which we’re shortening to “DistDoc”). The group aims to produce a proof of concept for distributed open science hardware (OScH) manufacturing, exploring key aspects like quality, documentation, business models and more using as a starting point a paradigmatic case study. We hope the experience motivates others to discuss and implement new strategies for OScH expansion.
By Shannon Dosemagen
Summary of this week: We discussed what would be the motivation for manufacturers to join this initiative, and came up with the prioritization concept.
The output of session three was the outline of a potential distribution agreement, annotated with considerations emerging from the GOSH manifesto. Focusing on one of its components, session four began by considering the merits and challenges of implementing a quality mark and thinking through questions such as:
- What are the values included in the mark (openness, quality standard, support for designers)?
- How does a new mark become valued (alongside other quality certifications)?
- How does the mark provide value for the local manufacturer?
Spending time on these questions kept circling us back to bigger pragmatic considerations (those along the lines of “why are we here”) about the structure of the collaborative, and the ways in which social and legal contracts would bind us. We also began to grapple with one of the biggest questions that structures as such have had — how to create financial sustainability amongst products that are open source? Going down this path, we re-centered our conversation on the tension between knowledge openness and capacity and resource management, through the concept of exclusivity — where and how we prioritize resources and capacity while maintaining sustainability.
However, exclusivity as a value didn’t quite align with our previous work and thus we substituted it for “priorities”. Why is this important? In many OScH projects we see how the philosophy of openness directly determines how capacity and resources are distributed. In general terms, everyone needs technical support and assistance so everyone gets it. But how sustainable is that when 1) a community is managing the project or 2) a developer is managing the project?
We therefore defined and included prioritization in our value set, as a way to describe how resources can be managed to ensure sustainability while recognizing the intrinsic values of open source. Prioritization doesn’t shut out groups, instead it provides precedence to be part of something larger than oneself (or one’s company), to work along the goals, priorities and practices of the group, and to value the greater vision of managing collective assets, products and workflows.
How does prioritization work in action? Let’s say two small manufacturers in the same region want to produce an open hardware product. Both are able to do so because of the open (and well-documented) designs that allow them to follow quality assurance protocols. One of them has engaged with the developer team of the product, and is therefore part of the manufacturing collective instrumented via contractual agreements. This turns into advantages for this manufacturer, as they have priority access to resources from the dev team, including support from project developers for troubleshooting components if the need arises.
And this indeed plays back into our goal and guiding values. Coming out of session four, we decided to take the distribution agreement/outline from session three and prioritize decisions we needed to make moving forward.
