Public Lab Research note


  • 3

When is it OK to work with non-open components in open source work?

by warren with liz |

At Public Lab, perhaps more so than in other open hardware oriented communities, we're often remixing and re- or even mis-using off-the-shelf parts, like the point and shoot cameras in our Balloon Mapping techniques. Sometimes, parts that aren't open source themselves! (Above image: open source kites, cameras?)

But really, almost any open source tools or techniques use /some/ components that aren't open source, even if it's just duct tape or, say, a resistor. This is not to say we don't need to think about these things, or work towards more open components -- and the Open Hardware Certification by OSHWA gets at this nicely (full disclosure, I'm vice president of the OSHWA board):

Ensure all parts within the creator's control are open source. Use best efforts to distinguish any third-party proprietary components. Third-party components such as chips [ed: here they mean microchips] must have fully accessible and shareable datasheets for hardware to be considered open source.

They go on in their "Creator Contribution" Requirement:

As noted above, in order to be certified under this program all parts, designs, code, and rights under the control of the creator must be made open according to the open source hardware definition hosted by OSHWA. However, that does not necessarily mean that the entire project must or will be open source. If the creators used third party closed components outside of their control, they are unable -- and are therefore not required -- to open souce those components. While it is strongly prefered to use open components when possible, OSHWA recognizes the reality that this is not always possible. The "creator contribution" requirement is an intentionally flexible one, designed to be applicable to individuals working alone and multinational corporations.

So among other things, it's extra important to clearly state what is and what is not open source!

Outside the box

At Public Lab, we think a lot about this because some methods don't currently have open hardware equivalents, and although we're interested in those, we think of open hardware more broadly than just what's inside a particular device or object. We're committed to open sourcing the practices that put an object to use -- the instructions, the setup, the experimental design, and the social practices that people use to put these things to work, learn and teach one another, and transform tools through reimagining their use.

With that in mind, and with an eye towards helping people investigate environmental problems, we use some of the following questions as a guideline:

  • A Canon camera is not open source, but we use it in our open source balloon mapping methods -- same with a Mobius camera. A $100,000 electron scanning microscope is not open source -- could we incorporate that method?
  • A method or technique can be open source if the means to reproduce the steps are openly and thoroughly published under open source licenses. By rough analogy, an open source website can be viewed on a closed source browser, or an analytic technique using commercial, non-open test tubes could have open source documentation.

What factors do we consider?

  • Are the components widely available and affordable?
  • Can all components be swapped for alternatives which are cheaper or just equivalent (another brand of camera, another type of microscopy)?
  • Does any component "lock" practitioners into an ecosystem or platform that (by design or due to lack of alternatives) presents significant barriers to escape?
  • Basically, are all components easily swappable "commodities" and not specialized equipment that are hard to get?

One reason this makes sense is that if we develop a set of practices (usage in the field, a group with literacy and expertise, means to learn and teach a technique) around a component (tool) that is closed, we ought to be able to switch over to an open alternative as it becomes available.

The skills we build as a community of practice should transfer. This has the added benefit that we shouldn't feel as "competitive" choosing between different tools -- because we should be able to switch between them.



open-source open-hardware blog oshwa hardware closed-source proprietary-tools

with:liz


0 Comments

You must be logged in to comment.