Microfactory Boot Camp - Every Hardware Build is a Fork

From Open Source Ecology
Jump to: navigation, search

Overview

One of the critical distinctions between open source software and open source hardware is that every single build replication is effectively a fork - unless an identical process was used to build the hardware. This is not possible, because by definition - different builds use different resources and are produced under specific conditions. It is not possible to replicate two realities as exactly as it is possible in software.

This imposes additional requirements for development documentation. Likewise, this also limits the relevance of Github as a 'silver bullet' for development coordination. Paradoxically, Github would not be able to scale for hardware, and a more generalized database approach is more suitable for tracking hardware forks. Moreover, Githib is suitable for about 10% of the assets generated in open hardware development, with other platforms such as Wikis, YouTube, and other media platforms being more suitable. This overview video touches upon more details of the every hardware replication as a fork consideration.

Git-based workflows are less inclusive than Merge Workflows, if evaluated from OSE's Vision. Git workflows are more technically-advanced than OSE's merge workflows and development protocol - though it can be said that OSE's workflow is more advanced in terms of the Collaborative Literacy required to execute the OSE workflow. The collaborative literacy part is critical for large, interdisciplinary teams (not just computer-savvy people) to collaborate.

Video

Content

This video continues from the previous video - Microfactory Boot Camp - Collaborative Literacy - OSE Linux, Design Jams and Extreme Manufacturing - which ended with the discussion of the Dashboard as an organizing wiki page for a scalable parallel development process that can be used in conjunction with HeroX design challenges. This continues to:

  • 3:05 - the function of the Development Template as an organizing framework for the overall development process.
  • 3:30 - Development Template
  • 8:25 - Different versions are kept at the Genealogies page, such as the 3D Printer Genealogy
  • 10:16 - Templates allow for scalable organization, but a user and maintainer community must be present to manage the templates.
  • 11:15 - Development templates can be created for different scales of organizations: machine ecologies, machines, modules, submodules.
  • 11:49 - Relevance of Github and concept of every independent replication effectively being a fork
  • 14:55 - Going through the Development Template and whether Github should be used for each step. The answer is that only 10% of the Development Template lends itself well to Github.
  • 17:55 - The end game for open product development is that any company in the world has a common pool of design and techniques to begin product development by reusing modules, thereby not reinventing the wheel every time a new product is designed.
  • 18:55 - Open source development is more likely in the limit of high complexity. This is already visible with software, such as with Artificial Intelligence and Computer Vision - but the same trend applies to hardware.