Genealogies - Revision history

Marcin: /* List */

2025-10-25T00:53:38Z

List

← Older revision		Revision as of 00:53, 25 October 2025
Line 32:		Line 32:
	*[[Trencher Genealogy]]		*[[Trencher Genealogy]]
	*[[CNC Circuit Mill Genealogy]]		*[[CNC Circuit Mill Genealogy]]
			*[[Gasifier Genealogy]]

	=Notes=		=Notes=

	[[Category:Product Genealogy]]		[[Category:Product Genealogy]]

Marcin at 16:46, 2 October 2025

2025-10-02T16:46:13Z

← Older revision		Revision as of 16:46, 2 October 2025
Line 1:		Line 1:
	{{Hint\|Last updated Aug ~~2022~~}}		{{Hint\|Last updated Aug 2025}}

	=About=		=About=

Marcin at 00:08, 4 August 2022

2022-08-04T00:08:36Z

← Older revision		Revision as of 00:08, 4 August 2022
Line 1:		Line 1:
	{{Hint\|Last updated ~~Dec 2021~~}}		{{Hint\|Last updated Aug 2022}}

	=About=		=About=

Marcin: /* Advanced Discussion */

2022-08-04T00:08:16Z

Advanced Discussion

← Older revision		Revision as of 00:08, 4 August 2022
Line 8:		Line 8:

	==Advanced Discussion==		==Advanced Discussion==
	In the way we build, we also consider the production engineering of the [[Second Toyota Paradox]] - ie, excessive prototyping. ~~Therefore~~, one does not know a priori which forks or variants will succeed in production. For this reason, one must keep track of all of the variants - as one never can predict which one will be useful at what time. We thus assume that all potential variants are useful - and if not useful in production, they are useful for purposes of organizational learning. Thus, while there may be an official branch that is ~~taken to production~~, other potential branches are never deleted or buried. We do this by retaining all development ~~variant~~ in the genealogy.		In the way we build, we also consider the production engineering of the [[Second Toyota Paradox]] - ie, excessive prototyping. In such a process, one does not know a priori which of the multiple prototypes, forks, or variants will succeed in production. For this reason, one must keep track of all of the variants - as one never can predict which one will be useful at what time. We thus assume that all potential variants are useful for production - and if not useful in production, they are useful for purposes of organizational learning. Thus, while there may be an official branch that is a clear product release candidate, other potential branches are never deleted or buried. We do this by retaining documentation of all development variants in the genealogy.

	If there are multiple teams worldwide working on different branches - coordination should still occur so that it is known which version a specific product is building upon - so that the development can be replicated.		If there are multiple teams worldwide working on different branches - coordination should still occur so that it is known which version a specific product is building upon - so that the development can be replicated, improved, synergized, and stygmergized.

	It is industry standard in mainstream (2022) product development to forget all the complexity of multiple project tracking as we do at OSE. That is natural in a proprietary development system, where one does not build on the competition's developments - or at least denies doing so in public. Nor does one document improvements made by stealing designs from others. All this is buried, as collaboration does not occur as a general practice, and many players continue to reinvent the wheel while producing inferior products. The higher level of discipline in documenting multiple development paths can lead to improved design by improved collaboration. OSE is working on this new development paradigm~~. There's nothing novel about our goal~~ - ~~it's~~ just a matter of shifting the paradigm to collaborative design.		It is industry standard in mainstream (2022) product development to forget all the complexity of multiple project tracking as we do at OSE. That is natural in a proprietary development system, where one does not build on the competition's developments - or at least denies doing so in public. Nor does one document improvements made by stealing designs from others - for reasons of secrec or even liability. All this is buried, as collaboration does not occur as a general practice, and many players continue to reinvent the wheel while producing inferior products. The higher level of discipline in documenting multiple development paths can lead to improved design by improved collaboration. OSE is working on this new development paradigm - whcih is just a matter of shifting the paradigm to collaborative design. This is not novel, it is only courageous. As such, one must become [[Radical Man]] to engage in this process.

	=List=		=List=

Marcin: /* Advanced */

2022-08-04T00:02:07Z

Advanced

← Older revision		Revision as of 00:02, 4 August 2022
Line 7:		Line 7:
	To understand how genealogies are named - one must start with considering that every build must be documented separately and as fully as possible. In other words - one must understand the meaning of [[Every Build is a Fork]]. Note also - that each product may have different models. A genealogy may be set up for each product. If so, the number of documented products (and their versions) is larger than the number of documented models. For example, Rosebud 3 may be the 4th iteration of the Seed Eco-Home - where the Seed Eco-Home is the main product, with various sub-models. Further - the Seed Eco-Home is the new colloquial name for the [[Microhouse]], since the Seed Eco-Home is a much more descriptive term for how we are implementing the Microhouse builds.		To understand how genealogies are named - one must start with considering that every build must be documented separately and as fully as possible. In other words - one must understand the meaning of [[Every Build is a Fork]]. Note also - that each product may have different models. A genealogy may be set up for each product. If so, the number of documented products (and their versions) is larger than the number of documented models. For example, Rosebud 3 may be the 4th iteration of the Seed Eco-Home - where the Seed Eco-Home is the main product, with various sub-models. Further - the Seed Eco-Home is the new colloquial name for the [[Microhouse]], since the Seed Eco-Home is a much more descriptive term for how we are implementing the Microhouse builds.

	==Advanced==		==Advanced Discussion==
	In the way we build, we also consider the production engineering of the [[Second Toyota Paradox]] - ie, excessive prototyping. Therefore, one does not know a priori which forks or variants will succeed in production. For this reason, one must keep track of all of the variants - as one never can predict which one will be useful at what time. We thus assume that all potential variants are useful - and if not useful in production, they are useful for purposes of organizational learning. Thus, while there may be an official branch that is taken to production, other potential branches are never deleted or buried. We do this by retaining all development variant in the genealogy.		In the way we build, we also consider the production engineering of the [[Second Toyota Paradox]] - ie, excessive prototyping. Therefore, one does not know a priori which forks or variants will succeed in production. For this reason, one must keep track of all of the variants - as one never can predict which one will be useful at what time. We thus assume that all potential variants are useful - and if not useful in production, they are useful for purposes of organizational learning. Thus, while there may be an official branch that is taken to production, other potential branches are never deleted or buried. We do this by retaining all development variant in the genealogy.

Marcin: /* Advanced */

2022-08-04T00:01:47Z

Advanced

← Older revision		Revision as of 00:01, 4 August 2022
Line 12:		Line 12:
	If there are multiple teams worldwide working on different branches - coordination should still occur so that it is known which version a specific product is building upon - so that the development can be replicated.		If there are multiple teams worldwide working on different branches - coordination should still occur so that it is known which version a specific product is building upon - so that the development can be replicated.

	It is industry standard in mainstream (2022) product development to forget all the complexity of multiple project tracking. That is natural in a proprietary development system, where one does not build on the competition's developments~~, nor~~ does one document improvements made by 'stealing' designs from others. All this is buried, as collaboration does not occur as a general practice.		It is industry standard in mainstream (2022) product development to forget all the complexity of multiple project tracking as we do at OSE. That is natural in a proprietary development system, where one does not build on the competition's developments - or at least denies doing so in public. Nor does one document improvements made by stealing designs from others. All this is buried, as collaboration does not occur as a general practice, and many players continue to reinvent the wheel while producing inferior products. The higher level of discipline in documenting multiple development paths can lead to improved design by improved collaboration. OSE is working on this new development paradigm. There's nothing novel about our goal - it's just a matter of shifting the paradigm to collaborative design.

	=List=		=List=

Marcin: /* Advanced */

2022-08-03T23:58:09Z

Advanced

← Older revision		Revision as of 23:58, 3 August 2022
Line 8:		Line 8:

	==Advanced==		==Advanced==
	In the way we build, we also consider the production engineering of the [[Second Toyota Paradox]] - ie, excessive prototyping.		In the way we build, we also consider the production engineering of the [[Second Toyota Paradox]] - ie, excessive prototyping. Therefore, one does not know a priori which forks or variants will succeed in production. For this reason, one must keep track of all of the variants - as one never can predict which one will be useful at what time. We thus assume that all potential variants are useful - and if not useful in production, they are useful for purposes of organizational learning. Thus, while there may be an official branch that is taken to production, other potential branches are never deleted or buried. We do this by retaining all development variant in the genealogy.

			If there are multiple teams worldwide working on different branches - coordination should still occur so that it is known which version a specific product is building upon - so that the development can be replicated.

			It is industry standard in mainstream (2022) product development to forget all the complexity of multiple project tracking. That is natural in a proprietary development system, where one does not build on the competition's developments, nor does one document improvements made by 'stealing' designs from others. All this is buried, as collaboration does not occur as a general practice.

	=List=		=List=

Marcin: /* Howto */

2022-08-03T23:52:27Z

Howto

← Older revision		Revision as of 23:52, 3 August 2022
Line 5:		Line 5:

	=Howto=		=Howto=
	To understand how genealogies are named - one must understand the ~~concept~~ of [[Every Build is a Fork]]. Note also - that each product may have different models. A genealogy may be set up for each product. If so, the number of documented products (and their versions) is larger than the number of documented models. For example, Rosebud 3 may be the 4th iteration of the Seed Eco-Home - where the Seed Eco-Home is the main product, with various sub-models. Further - the Seed Eco-Home is the new colloquial name for the [[Microhouse]], since the Seed Eco-Home is a much more descriptive term for how we are implementing the Microhouse builds.		To understand how genealogies are named - one must start with considering that every build must be documented separately and as fully as possible. In other words - one must understand the meaning of [[Every Build is a Fork]]. Note also - that each product may have different models. A genealogy may be set up for each product. If so, the number of documented products (and their versions) is larger than the number of documented models. For example, Rosebud 3 may be the 4th iteration of the Seed Eco-Home - where the Seed Eco-Home is the main product, with various sub-models. Further - the Seed Eco-Home is the new colloquial name for the [[Microhouse]], since the Seed Eco-Home is a much more descriptive term for how we are implementing the Microhouse builds.

			==Advanced==
			In the way we build, we also consider the production engineering of the [[Second Toyota Paradox]] - ie, excessive prototyping.

	=List=		=List=

Marcin: /* List */

2022-08-03T20:28:29Z

List

← Older revision		Revision as of 20:28, 3 August 2022
Line 25:		Line 25:
	*[[Trencher Genealogy]]		*[[Trencher Genealogy]]
	*[[CNC Circuit Mill Genealogy]]		*[[CNC Circuit Mill Genealogy]]

			=Notes=

	[[Category:Product Genealogy]]		[[Category:Product Genealogy]]

Marcin: /* List */

2022-08-03T20:28:16Z

List

← Older revision		Revision as of 20:28, 3 August 2022
Line 9:		Line 9:
	=List=		=List=

			*[[Microhouse Genealogy]] - '''note that the housing project genealogy includes the Seed Eco-Home'''
	*[[3D Printer Genealogy]]		*[[3D Printer Genealogy]]
	*[[Microhouse Genealogy]] - '''note that the housing project genealogy includes the Seed Eco-Home'''
	*[[Tractor Genealogy]]		*[[Tractor Genealogy]]
	*[[Power Cube Genealogy]]		*[[Power Cube Genealogy]]