Ways of interacting with other open hardware projects

Not reinventing the wheel

Probably one of the biggest advantages of working open is that we can access the knowledge and experience of those creating before us, to build up our own projects without having to start from scratch. Most of the best practices in this series point towards that goal: making your project reusable by others.

However, one of the common traits we see in open hardware communities is that projects are developed and recreated multiple times, each time documented as if it was original work. This is not a bad thing in itself, we all learn by repetition and you have to start somewhere. It becomes a problem though when platforms become cluttered with duplicated documentation, or entire teams, effort and resources are dedicated to create something that can be found, literally, a couple of clicks away.

This is usually called “reinventing the wheel” and it tends to happen when we dive directly into making without checking what others have previously done. In general, we tend to avoid it, because it’s much more interesting to learn from others, replicate what they do and then add our own unique contribution! It also accelerates the field, and builds a more coherent knowledge base.

Working smart: original or derivative?

Before moving on, it is necessary to understand that there are multiple ways to engage with an open hardware project. As mentioned in “Building Open Source Hardware”, the open hardware definition states the approval to create hardware from the original design files, to make copies and distribute the design files themselves, or to create a derivative from the original design. Because open source hardware grants the right to make copies, the terms “clone” and “counterfeit” get thrown around a lot when talking about derivative works.

To make it clear:

  • Derivative: A derivative is open source hardware that has been altered or modified but is based on an original design by another person or company.

  • Clone or Copy: A clone or copy is an open source hardware product that has been directly copied and conforms with the Open Source Hardware Definition because it does not infringe on the trademarks of other companies.

  • Counterfeit: With a counterfeit piece of open source hardware, the trademark has been copied onto a clone or derivative piece of hardware and does not abide by the Open Source Hardware Definition because the trademark is not owned by the person or company creating the derivative. Proper attribution does not include copying trademarks. Copying trademarks is illegal.

You can be creating an original piece of hardware, or you can be creating a derivative or fork, meaning you take what someone else published and work on that. You can also contribute to an existing open hardware project without creating a derivative, e.g. when you translate or improve documentation, or report/solve bugs in the software that powers the hardware.

People usually make derivatives to alter a function of an existing project, to modify the form of the device, to lower the cost of a project and make it more accessible to users, to improve the design for manufacturing or sourcing of parts. Most derivatives are more or less copies of the original, and that’s fine. People build off improvements and ideas from others rather than reinventing the wheel each time. This process moves innovation forward at a more efficient and more productive pace.

As you can probably guess, this has much to do with use of licenses; we will dive more deeply into it in following modules. For now, think about the way in which you are coming into open hardware: are you creating original work or making a derivative project? Have you ever contributed to an existing project?

Assignment: Do some research on projects similar to yours!

To avoid reinventing the wheel, and once you have defined the purpose of your project, go out there and look for open hardware projects that you can use as references.

Maybe you found a proof of principle for a function you need? There is some usability feature you’d like to incorporate, or you found a project you love and you’d like to make a derivative for your own needs?

Make a list of at least 3 projects, including project name, link to documentation, and a short note of why that project is useful for you.

Resources

next: Building Blocks overview  

Help us improve content and suggest changes to this page.