Useful-source open hardware tree structure
Useful Source will enable straightforward documentation of stable release of open hardware systems, to empower great number of high-quality reproductions globally. Previously we have introduced the motivation behind useful source, now its basic mechanics is discussed.
Open hardware documentation does not uniquely compile into a physical object or system due to the need for human interpretation and skill throughout the replication process, effectively making each replication a fork of the project. The details and small changes during replication are attributed to skill and generally do not find their way into the documentation, as it is very difficult to merge them back into the original source. Thus, we are doing this differently:
- Stable system releases are generated by the core team / community, integrating all the available forks into stable releases, testing and documenting, increasing the quality.
- Every system is introduced as a tree structure of modules and sub-modules, enabling simple understanding of how the overall system works and how modules interact.
- Module denotes a set of sub-modules closely coupled with each-other and loosely coupled with the rest of the system.
- Sub-module is a standalone solution to a self-contained technical problem.
- Step-by-step instructions are created for every sub-module, for assembly of every module and for overall system assembly.
- Bill of materials is documented as logical assembly parts, containing the basic knowledge what the function of the part is.
- Several sets of physical parts lists can be available per system, enabling simple localization.
- Test-case instructions are defined for modules and the system, to verify correct operation and to enable compliant reproduction validation.
- All documentation is interactive, simply inserting all the information in the fork. Think of it as a printed set of slides you scribble to during a lecture, or a piece of paper you draw on while trying to make something. There is no need to build it in a form that fits a stable release, it only needs to be good enough for publishing and personal reuse. Debugging a particular construction or unit becomes straightforward, as build information is provided de-facto.
Diagrams always make understanding better. The overall system structure is shown below, with the information flow and connectivity.
Every module is a standalone unit and can be used to document any small project as a whole.
Instructions, by default, allow a number of different lists of physical parts to be associated with logical parts and thus supporting localization. The build process and instructions follow the inverted tree structure, where you start with assembling sub-modules and then assembling them in even larger systems, finally being able to apply test-case steps to validate the quality of the replication.