Open Know-How: Difference between revisions
Jump to navigation
Jump to search
(Created page with "=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 specif...") |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
=What is it?= | =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. | 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: | |||
#Jérémy Bonvoisin University of Bath | |||
#Richard Bowman University of Bath | |||
#Andre Maia Chagas The University of Sussex, Mozilla Fellow 18/19 | |||
#Kaspar Emanuel Kitspace.org | |||
#Martin Häuer OSE Germany | |||
#Brynmor John Field Ready | |||
#Andrés Barreiro Wikifactory | |||
#Kshitiz Khanal Kathmandu Living Labs | |||
#Andrew Lamb (Chair) Field Ready, Shuttleworth Fellow | |||
#Anna Lowe - Manufacturing Change - [https://www.linkedin.com/in/annalowe/?originalSubdomain=uk] | |||
#Jenny Molloy University of Cambridge | |||
#Neil Noble ex-Practical Action | |||
#Nathan Parker MakerNet.Work | |||
#Jon Schull e-Nable | |||
#Balthas Seibold GIZ | |||
#Julian Stirling University of Bath | |||
#Emilio Velis Appropedia | |||
#Michael Weinberg Open Source Hardware Association (OSHWA) | |||
#Tobey Wenzel Docubricks | |||
#Diderik van Wingerden Think-innovation.com | |||
=Pros= | =Pros= | ||
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. | #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. | ||
#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= | =Cons= | ||
The specification does not apply only to open source projects, so the 'open' in the 'Open Know-How' is misleading. Ethical-economy open source organizations such as OSE are not well-served, in | #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. | ||
#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. | |||
#Scope is only simple devices and electronics, not technology in general, therefore this does not address [[Technological Recursion]]. | |||
Latest revision as of 18:47, 12 July 2020
Website
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:
- Jérémy Bonvoisin University of Bath
- Richard Bowman University of Bath
- Andre Maia Chagas The University of Sussex, Mozilla Fellow 18/19
- Kaspar Emanuel Kitspace.org
- Martin Häuer OSE Germany
- Brynmor John Field Ready
- Andrés Barreiro Wikifactory
- Kshitiz Khanal Kathmandu Living Labs
- Andrew Lamb (Chair) Field Ready, Shuttleworth Fellow
- Anna Lowe - Manufacturing Change - [1]
- Jenny Molloy University of Cambridge
- Neil Noble ex-Practical Action
- Nathan Parker MakerNet.Work
- Jon Schull e-Nable
- Balthas Seibold GIZ
- Julian Stirling University of Bath
- Emilio Velis Appropedia
- Michael Weinberg Open Source Hardware Association (OSHWA)
- Tobey Wenzel Docubricks
- Diderik van Wingerden Think-innovation.com
Pros
- 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.
- 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
- 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.
- 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.
- Scope is only simple devices and electronics, not technology in general, therefore this does not address Technological Recursion.