View source for Open-O-meter

__FORCETOC__

<span style="color:#ff0000">'''<big>This page is not maintained anymore. For more recent and complete description of the Open-o-Meter, see our recent article in Procedia CIRP, "[https://www.sciencedirect.com/science/article/pii/S2212827118312095 Measuring Openness in Open Source Hardware with the Open-o-Meter]"</big>'''</span>

[[File:Open-o-meter gif small.gif|right|border|frame|caption|'''The Open-O-Meter''' (obsolete animation to be updated)]]

In spite of existing standards such as the [https://www.oshwa.org/definition/ 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<ref>see in the page "[[A guide to Open Source Hardware|guide to Open Source Hardware]]" and in the [[Glossary]] entry [[Glossary#Open source hardware | Open source hardware]] for a discussion of this topic.</ref>. 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 [http://www.oshwa.org/definition/ 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 [http://www.oshwa.org/2015/09/19/open-source-hardware-certification-version-1/ 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<ref>Balka, Kerstin, Christina Raasch, and Cornelius Herstatt. 2014. “[http://onlinelibrary.wiley.com/doi/10.1111/jpim.12102/abstract The Effect of Selective Openness on Value Creation in User Innovation Communities].” ''Journal of Product Innovation Management'' 31 (2): 392–407.</ref>:
* '''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 <u>and</u> 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:
* [[A guide to Open Source Hardware#Enable others to study your product|design files]] are published;
* [[A guide to Open Source Hardware#Assembly Instructions|assembly instructions]] are published;
* a [[A guide to Open Source Hardware#Part list|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 =

Advantages:
* 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.

Limits:
* 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=

* [https://www.mdpi.com/2071-1050/11/17/4746/htm Assessing the Openness and Conviviality of Open Source Technology: The Case of the WikiHouse], by Christina Priavolou and Vasilis Niaros.

* [http://peerproduction.net/wp-content/uploads/2019/03/Open-Source-beyond-software.pdf Open source beyond software: re-invent open design on the common's ground], by Kosmas Gavras

=References=