OSE Centralization

On Decentralization of OSE Work

As far as I understand Centralization - we have a centralized wiki. But anyone could fork it. OSE Germany already forked OSE in some way. But tell me more what exactly the issue and proposed solution would look like.

Well, you're building up a legacy here, but I think the contingency plan is not as good as it could be. What happens to the legacy when you proverbially get hit by a truck? (Or more relevant catch Corona, what the hell is going on in the US?!?) Git was designed such that the larger the community, the more clones (the complete version history) exist, so the project will not die if a core developer falls away. I'm aware of the wiki dump on archive.org, but there is a lot of information in external tools such as Google spreadsheets. All that will not be preserved and the dump is not automatically up-to-date.

Indeed, the wiki is centralized, so if the wiki falls away, it could in principle be re-established, but it is not as automatic as in git. Some form of decentralization could help with this. An obvious solution would be moving the development to git but that has drawbacks. Another solution would be to federate the wiki. I don't know if mediawiki supports this in any way, but someone must have thought about this. This would mean that multiple parties host the wiki and the accounts and everything is automatic synchronized and mirrorred. Another option is to move to Nextcloud which already supports federation.

Well, I don't have a good solution, but I was wondering if you were aware of the relative weakness of OSE in these aspects compared to for example Linux where each contributor has probably at least 1 complete clone of the Linux software.

I'm working a bit on a possible solution via git. I already have a prototype where I automatically generate a wiki page from some description files, BOM, and CAD files. If I find some time, I will create a demo video of this project and I will discuss the strengths and weaknesses of this attempt. It would work for me, but I'm not sure it would work for the OSE community. I do think it is important for the community to understand what is possible. I hope I find some time the coming days to update my log.

Pieter

MJ Sez

The true 'git clone' is 'git clone new civilization.' Translated - that means that enterprises - up to working resilient communities and even autonomous microstates - are intended to be replicated using OSE technoogy. That is a proof of the viability of OSE's designs.

I think the only real decentralization is enterprises that start around any product: that is a complete clone, including the production and enterprise part. In software, the product is compiled. In hardware, the equivalent is a manufactured product, using a nonuniform compiler, until complete Toolchain Degeneracy is attained (an impossibility). At that point, we have truly created the possibility of true 'git clone.' The only true decentralization is when a number of businesses start up using OSE technologies. We are working on enterprise replication explicitly with the OSE Chapters Proposal, starting 2020, to create operations in different locations. Part of workable enterprise replication would be toolchain degeneracy, otherwise there is no uniform compiler. A uniform compiler is required to clone something in real life.

Short of a true 'git clone new civilization,' we can certainly automate project documentation and storage at Gitlab. See G Log working on issues related to automated documentation. There is also another issue of memory size. To git clone new civilization, that requires massive amounts of data, including build videos and huge CAD files, which make it rather impractical for every user to have a complete cloned repo. Right now we're only at a few gig of wiki content, but we are at countless terabytes if video and other assets are included.