Open Hardware Distribution & Documentation Working Group: Interlude — Adjusting the Compass
This is the fifth 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 Julieta Arancio
Summary: We review the main goals of the project and steps moving forward, and assign tasks to dedicated working groups.
In session four the group discussed what the advantages were for manufacturers joining the collective, and came up with the concept of prioritization as a primary way to represent them. In session five we took a breath and, aided by questions from one of the participants, re-centered the group’s goals and next steps.
What’s the purpose of this group?
The purpose of this work is to support the transition of OScH from people’s garages (or academic labs) to the mass market as we try to hit the goal of ubiquity of OScH by 2025.
We know, through previous attempts, that this cannot be accomplished through project by project networking alone. We see individual projects reaching resource and capacity limits when they attempt distribution and production models like this on their own. A structure as we’re discussing can serve as a backbone — infrastructural support — for the wider distribution, adoption and use of open hardware.
What is the relationship between the group and the product dev team?
The main question here is who is making decisions on what. In the group we all have different expertise; some are developers, others document, others know about manufacturing processes and legal aspects. We need to fine tune which areas we need to work with and have people assigned to them to work autonomously, while ensuring that key discussions are still passed through the whole group. To build out autonomous workflows, we prioritized these goals over the next six months:
- Evaluation: Collect all of the background information in order to make informed and competent future planning decisions.
- OpenFlexure LTS: Complete the Long Term Support version of the OpenFlexure, get the files/docs/etc. fully into the appropriate toolchain.
- Toolchain choice: The toolchains for each Development team should be decided at this point. That means we can begin actively developing, coding, writing etc. in order to utilize those toolchains. For example, at the end of this milestone we should know we’re using software X, process Y, and output Z for our assembly documentation.
- OF toolchain complete: The OpenFlexure now has fully populated toolchains in the Legal, Documentation, and QA / QC toolchains. This should occur with continual feedback from the Manufacturing and Product Teams.
What are the production costs, competitive advantages and competitors of the product?
We need to produce this information on OpenFlexure in order to be able to propose a distribution agreement to manufacturers. This is an important task to complete so we can think of the market and motivations for manufacturers to join.
Are we interested in developing a network of independent consumer-facing manufacturers/distributors or a network of manufacturers who are all operating under a single brand?
This is still in discussion, but there are challenges to not operating under a single brand (e.g., common marketing). This still needs some review, as it’s related to agreements and what should be enforced by default with partners.
***
After identifying these key concepts, the next immediate steps assigned to specific working groups include: a) coming up with a set of questions to send to potential manufacturers in order to capture their interests and concerns, and b) work on the market-side of the OpenFlexure project aided by the business canvas and the open hardware canvas.
