Open Hardware Distribution and Documentation working group: A centralized hub to support decentralized distribution
This is the 12th post of the series of the Open Hardware Distribution and Documentation Working Group (which we’ve 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.
By Shannon Dosemagen
Many would argue that there are lots of ways to do fully decentralized models of distributed manufacturing. However most of the people in this working group represent small (but growing) businesses or a singular product that could benefit by the combined pooling of resources. While we would like to create value and profit from the products sold, we’re also field supportive and focused on creating an ecosystem for open hardware in which distributed manufacturing and distribution can thrive.
To this end, pooling of resources — people resources, finances, legal and contract models, etc. — helps to distribute both the responsibilities and provide resources that will shorten the uptake time as new groups and projects come into a cooperative setting. This centralization-at-points under a cooperative model helped to clarify barriers that we’d been discussing:
Slaying the idea of unicorns in open hardware: When there are limited resources, sometimes we’ll try to bundle a bunch of specialized and unrealistic responsibilities into one role — sales and business development, accounting, marketing, technical knowledge of multiple produces (including ability to troubleshoot and aid customers) of multiple products, customer services skills, etc. The approach of the unicorn implies that there are people that can carry out these tasks, many potentially a full job in and of themselves, across the open hardware landscape. As many of us in the working group have experienced, this just isn’t the case except in rare examples. Pooling resources between projects and organization can help to provide domain-specific knowledge for different projects when needed, and pool resources that allocate funding and attention to the gaps that are felt network-wide in roles and responsibilities. Instead of hiring someone to do five distinct things under one role for one organization, this means contributing resources towards ensuring that all members of the network have access to an excellent open hardware marketer, sales person or business development professional.
Creating a give/get based on unique contributions: There are core needs within a network that supports distributed manufacturing and production. For a cooperative model to function, we needed to collectively understand what each project, organization and non-associated individual could commit to giving in order to make a network like this function and also understand what they each expected to get in return. The “give” of these scenarios could include percentage financial resources, human resources, advisory support on technical components (both in projects and documentation), etc. The “get” could be that projects need such a network to increase their geographic reach, they receive support from experts in business-related topics, they see a percentage increase in the revenue being generated from their projects because of savings they are receiving elsewhere from being involved in the network.
Building a library of resources: The agreements between entities that are operating in different countries (and under different tax laws) is complex. This network would build up a library of documentation and resources that support organizations and projects in having easier inroads to creating and establishing agreements.
Building off of existing regional networks: Projects in our small working group have established partnerships with manufacturers and distributors in different parts of the world. Working within the network approach helps for groups to build new routes to places where their products and work may have previously been unknown.
The meetings we held in late February and early March 2021 solidified that we had a clear line of thinking for a model. We emerged from a blue sky vision that could solve all the distributed manufacturing and documentation issues, and came to a point that showed a path forward for a subset of our working group to pilot this model. Landing on this model acknowledged that not everyone would see the same benefit in the approach and that there would be a point in the near future where it was time to think about working group forks, wrap up and learnings (as we’ll discuss in the final upcoming posts of this series).
