Hi @rafaella.antoniou,
Sorry for late response. Below are my responses to the questions plus other thoughts, looking forward to critique.
What does open source hardware project success mean to you? i.e. examples of success factors
Open source hardware is derived from open source software, which itself can be traced back to the concept of free software. This is defined not as “free-of-charge”, but as a product which enshrines the four freedoms to study, share, modify, and re-distribute it (free software can, in fact, be commercially produced and sold).
For me, the success of an open source hardware project would depend on how much those freedoms are realised in real life. This may span from the publication of the hardware design and documentation under an open source hardware license, the reproducibility of the design, to other factors such as dissemination, publicity, and community involvement.
Contrary to what some might say, I believe commercial success is a great indicator of open source hardware success. If someone can create a profitable and sustainable business based on open source hardware, that’s great and should be celebrated and fostered!
As a scientist, I strongly believe that the knowledge production is inherently iterative where you are always standing on the shoulder of giants. Instead of re-inventing wheels, having the four freedoms for hardware (or software) makes standing-on-shoulders much easier!
What are some potential metrics for open source hardware project success? i.e. what could be used to measure success
The community that builds around open source hardware is commonly considered as a demonstration of its health, and I agree. Broadly speaking, metrics for success here can be publicity around the project; how often it is shared (e.g. forked); or if it has been modified. Of course, the size of the community (e.g. number of users on forums, email lists, website visitors, users in issue trackers, etc.) and how active it is (e.g. frequency of participation in forum threads) are also good to track.
One metric I care about a lot is the bus factor of an open source project. This measures how much the sustainability of a project heavily relies on one, or a few, people, and what would happen if this dependency is lost. If an open source hardware project has a contingency plan for “continuity of government” during expected loss of leadership or upheaval, then that’s a sign of maturity in its community organisation.
I also mentioned that commercial success should be encouraged for open source hardware (and indeed, software). Here, I guess conventional measures of business performance can be used, such as volume of products produced and sold, revenue, or profit. One example of a successful business is the Ultimate Hacking Keyboard (git repository here), which is fully open source and has been selling well for several years now.
One challenging metric might be “in-real-life reproducibility”. For example, how easy is it for someone else to manufacture a product based on design files from a git repository? Are the design files alone sufficient for reproduction? When documenting a project, it is often difficult for a developer to have sufficient empathy to put themselves in the shoes of someone completely new to the project, and lots of “know-how” is not communicated in the open-sourced hardware design. How to measure and improve upon the reproducibility metric is important to consider!
Lastly, I believe it would be very gratifying for an open source hardware developer to learn that their work has been useful to others, and that the design is being built on and utilised in creative ways outside of what was originally envisioned. I’m not sure of the best way to measure this, though, and would love to hear what others have to say about this.
What practices do you consider essential to successful open source hardware development projects? i.e. activities, artefacts
I think a fundamental best practice is to meet the definition of open source hardware by publishing a hardware design (and associated documentation) under an open source hardware license such as the CERN Open Hardware Licence 2.0. I consider this a success in itself, and all other metrics for success should require it. This may sound trivial, but I have seen projects which self-describe as “open source” without attaching an open source license to their designs, which legally prevents any open source development from happening. In addition, there are hardware projects that publish their design files but explicitly deny the freedoms of open source. An example of this would be the NumWorks graphing calculator, the design of which is released under the Creative Commons Attribution Non-Commercial No-Derivatives (CC BY-NC-ND) license that is by definition not open source.
Whenever possible, reasonable efforts should be made to employ free standards and specifications for open source hardware. This means using open source instead of proprietary file formats and software (e.g. FreeCAD instead of AutoCAD for design files), and following standards that improve the interoperability and machine-readability of what you publish (e.g. use the The Open Know-How Manifest Specification). Doing this well might help improve the reproducibility of a piece of open source hardware.