OSE Design Guidelines: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 2: | Line 2: | ||
These are design choices generally advised. However, there are always exceptions so the ultimate arbiter is self-determination, a layer above self-actualization and self-realization. | These are design choices generally advised. However, there are always exceptions so the ultimate arbiter is self-determination, a layer above self-actualization and self-realization. | ||
==Parts, Part Count, Degeneracy== | |||
*We focus on an admissible parts approach (APL=admissible parts list) for design transparency | |||
*We focus on the APL for [[Open Source Vertical Integration]] | |||
*Degeneracy trumps build time. If added build time is unacceptable, degeneracy is demoted. | *Degeneracy trumps build time. If added build time is unacceptable, degeneracy is demoted. | ||
*Degeneracy (unique part count) trumps part count. If the same part can be used, that is favored even if you have to add to part count. This is because number is easier to manage than diversity - from the build management perspective. | *Degeneracy (unique part count) trumps part count. If the same part can be used, that is favored even if you have to add to part count. This is because number is easier to manage than diversity - from the build management perspective. | ||
Latest revision as of 23:14, 2 May 2024
Principles
These are design choices generally advised. However, there are always exceptions so the ultimate arbiter is self-determination, a layer above self-actualization and self-realization.
Parts, Part Count, Degeneracy
- We focus on an admissible parts approach (APL=admissible parts list) for design transparency
- We focus on the APL for Open Source Vertical Integration
- Degeneracy trumps build time. If added build time is unacceptable, degeneracy is demoted.
- Degeneracy (unique part count) trumps part count. If the same part can be used, that is favored even if you have to add to part count. This is because number is easier to manage than diversity - from the build management perspective.
Links
- See also prior work at Meta Design Guide from 2019