From OPEN! - Wiki
Jump to: navigation, search

This page is not maintained anymore. For more recent and complete description of the Open-o-Meter, see our recent article in Procedia CIRP, "Measuring Openness in Open Source Hardware with the Open-o-Meter"

The Open-O-Meter (obsolete animation to be updated)

In spite of existing standards such as the Open Source Hardware (OSHW) Statement of Principles 1.0, the term open source when applied to hardware remains quite fuzzy and it is not clear how to make the difference between what is open source and what is not[1]. This fuzziness raises salient questions for practice:

  • What is the minimum I should do so I can label my product "open source"?
  • Where does openness stop and "open-washing" start?
  • Can we say that a product is more open than another?

This page intends to bring some practical insights to these questions.

Open source: a multidimensional and gradual concept

To date, existing definitions of open source hardware do not draw a clear line between which piece of hardware can be qualified as open source and which cannot. There are to date no official requirements that need to be fulfilled in order to call your project "open source". The Open Source Hardware Statement of Principles 1.0 of the Open Source Hardware Association (OSHWA) states: "Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design.". But what does it mean to "make a design publicly available"? What are the documents that enable others to study, distribute, make or sell your design?

A general rule of thumb is that the least you should do is to share the design files in original formats for all parts that you are designing by yourself. The OSHWA is introducing a self-certification programme for open source hardware based on this rule. But this forgets about the thing that open source is not only about allowing people to study the product, but also to make it and to modify it. An that the information you should share so people can study your product may be different than the information you should share to enable them making and modifying it (see A guide to Open Source Hardware). And what about products whose design files are not published but for which assembly instructions are available? Aren't these products open source as well?

This shows we may need a finer definition of open source out there. Part of the solution is given by considering that openness includes three distinct aspects[2]:

  • Transparency: the possibility for any interested person to see how the product is designed;
  • Replicability: the possibility for any interested person to make the product.
  • Accessibility: the possibility for any interested person to take part in the (further) development of the product;

These theoretical aspects give practical insights about what has to be shared so you can label a product open source:

  • design files: so people can see how the product is designed (transparency);
  • assembly instructions and bill of materials: so people can make the product (replicability);
  • all the files you share shall be editable so people can edit them and eventually contribute back to their further definition (accessibility).

One question remains: does a product need to be transparent, replicable and accessible so you can label it open source? Or is it enough to satisfy only one of these requirements? In other words: from both questions "is this product open source?" and "how far is this product open source?", which one is the most relevant? In the following, we consider it would be too much to expect that one product satisfies the three requirements before it can be called open source. We therefore introduce a flexible assessment indicator allowing to measure "how far is a product open source".

Introducing the open-O-meter

The open-O-meter is a simple scale from 0 to 8 where a product gets one point for each of the following aspects:

  • design files are published;
  • assembly instructions are published;
  • a bill of materials is published;
  • a contribution guide is published;
  • the published CAD files are in editable format;
  • the published assembly instructions are in editable format;
  • the published bill of materials is in editable format;
  • all this information is published under a license allowing commercial reuse.

It is simple:

  • if a product gets 8 points, it conforms to the best practices of open source hardware.
  • if a product gets 0 points, it does not seem to be open at all and should not be labeled as open source.
  • if a product gets between 1 and 7, it is on it's way!

You can find a list of open source products with their respective open-O-meter values here: List of open source hardware products.

Advantages and limits


  • Well, this is the best assessment scheme we have.
  • It allows a common reference for all open source products.
  • It is flexible and shows the whole range between best practices and open-washing.


  • It does not take into account the quality of the published documents (e.g. how exhaustive are the published design files or how easy to follow are assembly instructions). In that sense, this indicator is based on plausibility rather than on conformity. Indeed, it would be difficult to assess the conformity of the shared files because of a lack of precise quality requirements. But it is simple to verify whether at least something is done to address the requirement.
  • It gives a similar weight to each requirement. Whether these requirements are equally importants is a question that should be discussed in the open source hardware community and we cannot answer here.

They talk about it


  1. see in the page "guide to Open Source Hardware" and in the Glossary entry Open source hardware for a discussion of this topic.
  2. Balka, Kerstin, Christina Raasch, and Cornelius Herstatt. 2014. “The Effect of Selective Openness on Value Creation in User Innovation Communities.” Journal of Product Innovation Management 31 (2): 392–407.