Open Hardware Distribution and Documentation Working Group: Same brand, different products

Julieta Arancio Open Science Hardware News 2 Comments

Source: Chucks Mbat

This is the seventh 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.

Tl;dr: the group decides to focus on the production process of two kinds of microscopes, for educational purposes and for research.

With the main building blocks of the process defined during the last weeks (see post 6), the team moved on to define some concrete lines of work. As happens with other open hardware projects, and in particular open hardware for science, one product has multiple “flavours” or assembly schemes that fulfill different needs. Considering manufacturer’s experience, market and simplicity, the team chose two models to work on:

  • An Open Flexure microscope for education and hobbyists, lower cost, medium accuracy
  • An Open Flexure microscope for research, higher cost, professional-grade

The main difference between both products is that the research grade microscope is motorized and the optics are better, avoiding chromatic aberrations. The educational microscope is good enough to teach microscopy, and in fact can take advantage of aberrations as a way of teaching about problems in microscopy. The Cameroonian manufacturing team partners also mentioned how a lower cost version can help sustain a higher cost one from a business point of view.

While the group is still working on tools integration (SurveyStack <-> GitBuilding), the developer team is making efforts to video-document the building process as much as possible, so manufacturers can jump in with less friction. The “two-flavours” model will also serve as a good test of toolchain integration, representing a common situation in open science hardware projects.

With the products defined, one of the main topics we covered is the creation and implementation of a hardware mark. The next question that emerged was “who is responsible for the mark?” Thinking of what gives value to a mark, the group related value to the effort in advertisement and enforcement of its use. Who would put in those efforts to manage and maintain a mark for a collaboration like this? Is there any administrative capacity in our group, allocated for the task?

The team agreed that the GOSH community seems to be in a position to potentially support this kind of work in the long term, but would require broader community consultation. In the short term, to provide a proof of concept, the group agreed that it would be good to start working with the resources already available rather than jumping right to a legal structure. This would also help us to build a better case, as a group, to present to the community afterwards.

One of the key requirements for this “loose” methodology to work is trust. Trust between the developer team and manufacturers, forged through being part of the same community and having shared co-development and capacity building in the past. Considering this, the group is moving forward with a handshake agreement, to explore in these 3–6 months what it means to be partners in producing OSH in a distributed way.

Comments 2

  1. 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.

    1. Post
      Author

      That’s a great question, thanks for commenting. We’ve talked about this in the group, we’ll write up some thoughts in January to share back with you.

Leave a Reply

Your email address will not be published. Required fields are marked *