Genealogies

From Open Source Ecology
Jump to: navigation, search


HintLightbulb.png Hint: Last updated Aug 2022

About

The Genealogy is a listed history of projects or versions upon which the current project builds. Projects other than OSE can be included here - since all open source work should be derived from existing work. The genealogy informs a Roadmap for future work. When creating a new version, add that to the genealogy. If a genealogy does not exist yet (for example if only one version exists), create the genealogy for that project. See Wiki Taxonomy. To start a new development project, the official wiki templates used are [[Template:dev+]] and [[Template:Enterprise]]

Howto

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 Discussion

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, 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 - 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

Notes