Open Know-How

From Open Source Ecology
Jump to: navigation, search

Website

http://okh.ludwigcorp.eu/

What is it?

The Open Know-How Specification is a specification and format for how to communicate information about products. The specification is open source, OSHWA compliant. The specification is used to communicate how to communicate about hardware knowledge.

Authors

Study the organizations involved:

  1. Jérémy Bonvoisin University of Bath
  2. Richard Bowman University of Bath
  3. Andre Maia Chagas The University of Sussex, Mozilla Fellow 18/19
  4. Kaspar Emanuel Kitspace.org
  5. Martin Häuer OSE Germany
  6. Brynmor John Field Ready
  7. Andrés Barreiro Wikifactory
  8. Kshitiz Khanal Kathmandu Living Labs
  9. Andrew Lamb (Chair) Field Ready, Shuttleworth Fellow
  10. Anna Lowe - Manufacturing Change - [1]
  11. Jenny Molloy University of Cambridge
  12. Neil Noble ex-Practical Action
  13. Nathan Parker MakerNet.Work
  14. Jon Schull e-Nable
  15. Balthas Seibold GIZ
  16. Julian Stirling University of Bath
  17. Emilio Velis Appropedia
  18. Michael Weinberg Open Source Hardware Association (OSHWA)
  19. Tobey Wenzel Docubricks
  20. Diderik van Wingerden Think-innovation.com

Pros

  1. A universal format for information about products makes them discoverable. It allows one to assess the license of projects readily. It is a general purpose tool that facilitates open source collaboration.
  2. The question seems to be mal-formed: what problem are we solving for? Discoverability of information on other projects? Discoverability of closed source projects? I don't know how to think about it. There is high usefulness in discovering closed sourceness- so we avoid closed projects. But it seems that we would be better served by serving open projects - why give attention to closed source? How to think about it? It's like looking at a glass half full vs half empty - it's a choice of perspective, but with important practical consequences.

Cons

  1. The specification does not apply only to open source projects, so the 'open' in the 'Open Know-How' is misleading. IT is open knowledge on closed projects - how to reconcile the name? This is yet another obfuscation of the work 'open'. I would use another name instead of open, which is too close to 'open source'. Need to address license ambiguity (open vs not) up front, this is not a good start.
  2. Ethical-economy open source organizations such as OSE are not well-served because Tool Chain Degeneracy is not addressed a priori. This makes distributed quality control not possible.
  3. Scope is only simple devices and electronics, not technology in general, therefore this does not address Technological Recursion.