This is the third post of the series on the Open Hardware Distribution and Documentation Working Group (shortened 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. This post is a continuation of part 1 of values-based standards for manufacturing.
Read the first post “Introduction” here.
By Shannon Dosemagen
During session two, we worked through values-based distribution agreements. In the third session we started to uncover what these values signify and require. Building on the values mapping exercise we did between the GOSH manifesto (2016) and distributed manufacturing practices (documented in session one), we now can focus on discussing the utility that a collective distribution approach could model for the broader landscape of OScH in the long term.
We started by asking what the mapping of values to the activities of manufacturing would look like in concrete terms. For instance, one value in the manifesto is “GOSH has no black boxes” which doesn’t necessarily map with ease onto distributed manufacturing practices. We dug into what this means when put to practice, and concluded that an OScH project that has no black boxes, when produced and distributed globally “provides local technical support and maintenance options”.
We then considered if this application of the GOSH values also maps to the values, for instance, of OpenFlexure (as the initial project we’re modeling from). With long-term sustainability as a core goal for OpenFlexure, is the promise of providing local technical support and maintenance options without overloading the project team a reality? We added this to our list of questions to address.
This brought up the consideration that while some materials we need to work with may not demand a complete rewriting (such as distribution agreements and manufacturing contracts), they may require us to apply our values in different ways. To begin shifting our workflow towards some of the decisions to be made in light of our conversations on values, we began drafting a set of potential questions to answer into the format of a distribution agreement:
- Access to trademark (or other mark to be determined)
- Supporting marketing and sales zones
- International processes for improvements and sharing
- Structure:
- Collective-wide constitution
- Responsibilities of collective
- Product by product constitution
After building out the above structure we created a second segment of prompts based on how distributed manufacturing practices lineup with our previous values mapping. The above began to look like:
1. Access to trademark (or other mark to be determined)
i. What are the values included in the mark (openness, quality standard, support for designers)?
ii. How does a new mark become valued (alongside other quality certifications such as the OSHWA OH certification)?
iii. How does the mark have value to the local manufacturer?
2. Supporting marketing and sales zones
i. How do developers/designers build in termination clauses that allow them to move between distributors?
ii. How do sales zones help (or not) to aggregate demands?
3. International processes for improvements and sharing
i. What is the value-add to members of the (yet to be determined) collective? For instance, can we make tools available as open source but uphold a structure to populate and put in place local processes?
4. Structure
i. Collective-wide constitution
- How does it track against a collective-wide plan for economic and environmental sustainability?
- How do we do equity-based assessments and improvement plans?
- How does a constitution ensure fair labor practices of distributed manufacturers?
ii. Responsibilities of collective
- What does a system for pooling requests and contributions from members to get additional improvements to the hardware look like (e.g. that aren’t on the developer’s roadmap and they would not do otherwise)?
- How do we help navigate local regulations, necessary insurances (e.g. product liability), external testing and certification that might be required?
- What does maintenance of software tools to help with QA/QC or private sharing and support between members look like?
iii. Product by product constitution
- What specs need to be hit to receive a quality mark on the product?
- How are those specs identified and maintained (between product developers and manufacturers)?
With this values-based structure in place we feel we are ready to introduce in the next posts the different concrete tasks the group is working on to build a case for OScH distribution.