Continuous Integration for Hardware: Difference between revisions
(Created page with "Th analogue of Continuous Integration in software - but applied to hardware. Naturally, Continuous Integration for Hardware is much harder than software, because real buil...") |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 3: | Line 3: | ||
OSE is pioneering methods through its education program where a scale-unlimited process for collaborative hardware development is taking place and being refined. | OSE is pioneering methods through its education program where a scale-unlimited process for collaborative hardware development is taking place and being refined. | ||
In practice, as OSE starts its 24 person apprenticeship, the development process extends to setting standards and developing [[Degenerate]] construction sets for technologies, with built-in processes for [[Concurrent Engineering]]. | In practice, as OSE starts its 24 person apprenticeship, the development process extends to setting standards and developing [[Degenerate]] construction sets for technologies, with built-in processes for [[Concurrent Engineering]] along the lines of the [[Second Toyota Paradox]]. How do you go from one product and 24 developers to thousands of developers and hundreds of product ecologies that follow a consistent pattern language? That is the question we are answering. | ||
Latest revision as of 22:37, 7 September 2023
Th analogue of Continuous Integration in software - but applied to hardware. Naturally, Continuous Integration for Hardware is much harder than software, because real build and performance data must be considered, in the presence of a distributed compiler. Huh? Where do we even start?
OSE is pioneering methods through its education program where a scale-unlimited process for collaborative hardware development is taking place and being refined.
In practice, as OSE starts its 24 person apprenticeship, the development process extends to setting standards and developing Degenerate construction sets for technologies, with built-in processes for Concurrent Engineering along the lines of the Second Toyota Paradox. How do you go from one product and 24 developers to thousands of developers and hundreds of product ecologies that follow a consistent pattern language? That is the question we are answering.