OSE Centralization

On Decentralization of OSE Work

MJ sez - 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.

Pieter - 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 autonomous microstates - are the true 'backups'. That is a proof of the viability of OSE's designs. And - a true backup is a real instance when we are dealing with hardware. If there are numerous real instances, there are numerous, decentralized 'backups'.

To answer more directly - 'git clone' of wiki is useful but incomplete. In part because 'pull requests' or overall value of our 'source code' can be determined only by examining real instances of builds. So yes - we can 'git clone', in the sense of much of the design. But currently this is not possible nor practical for complete documentation. Complete documentation involves terabytes of video documentation, or large CAD files, and diverse assets which cannot easily be reconciled as the official version. Which is not practical to replicate. But yes - when it comes to limited core documentation - most of it can be replicated via 'git clone'. What is the practical solution? When in Rome, do as the Romans. Translated - use Git for what is git-able (definitely source code) - but for other assets, such as video - use YouTube. For documents, use cloud editable docs. For renderings, use Blender. Use the appropriate tool as needed.

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.

What this implies - is that the product is part of the source code. Huh? Yes, because further developers cannot build upon the product if they don't have access to the product. This is an ultimate chicken-and-egg problem in terms of open hardware submitting itself to full documentation via 'git.'

Thus in practice, we can definitely decentralize the wiki. This is in our view not necessary when there are numerous instances of 'new civilizations' which serve as the ultimate source code.

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.