Technology Assessment

From Open Source Ecology
Jump to: navigation, search

The Technology Assessment is an analysis of the technology's openness, simplicity, buildability, efficiency, performance, cost, and other features - based on OSE specifications.


HintLightbulb.png Hint: Technology Assessment here refers to the assessment that OSE performs to determine whether a specific technology should be considered for open-sourcing.

After one has studied some Industry Standards, one can begin noticing design patterns. Then one can conclude what works and what doesn't in commercially available products. This is evaluated from the perspective of OSE Specifications, and specifically, their quantitative measurement via the OSE_Specifications_Score.

The basic assumption here is that any product can improve by becoming open source. This is based on the assumption that increased popular involvement in technosphere creation can only lead to improve the technosphere because of improved knowledge flows and feedback loops.

The technology in question could be a machine, a house, or a biological system.

Example

Take the case of an aquaponic system design that is available commercially. We know that in general, aquaponics works. The first question to ask is: is it open source, or which parts are documented such that OSE can build upon them? Second - does it work? Then a slew of other questions related to how well the system works and how appropriate it is from the standpoint of OSE Specifications? What can be used or modified to meet OSE Spec? For example - how does one master complex system management - especially integrated pest management - such that production remains viable? What is the highest level of diversity that can be implemented such that a single person can manage a productive operation? What are the input material costs? What are the input labor and maintenance costs? What are the societal and geopolitical impacts of the technology in terms of resource security and wealth distribution if this design is replicated?

These questions are asked, and then the designs are evaluated to inform the OSE team which paths to pursue or follow up with. The goal is to pick out the elements that OSE wants to replicate or work with, and decide to not follow certain other paths. What not to follow is as important as what to follow - and this inight is gained by filtering through OSE Specifications.

In general - if a technology is truly open source - meaning that the author is genuinely willing to share - then collaboration is useful. The OSE developer has to watch out for signs of Fake Open Source. The issue that needs to be identified early on is the license - as a lot of time can pass only for OSE to find out that the technology is not really open source - which is often the case as very few people understand the Open Source Definition.

Protocol

  • Take the existing Industry Standards that have been documented for the product according to the Industry Standards Protocol
  • Quantify the OSE Priority Filter:
  • Attach that score to the Industry Standards mindmap that has been generated with Coggle.
  • Embed result and edit link on the wiki.