Realtime Cloud Collaborative Editing
Contents
Intro
Realtime cloud collaborative editing - is the editing of documents and creation of digital assets - done over the internet - where a large group of people can edit the same document or asset at the same time.
Cloud refers to the documents being on-line - accessible by anyone anywhere in the world.
Realtime means that many people can edit at the same time, and see others' changes at the same time as they are made.
Collaborative means many people doing this together, and with realtime - at the same time.
Currently, OSE uses Google Slides for collaborative design and build documentation. OSE also uses Part Libraries for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time. This works by collaborators downloading and uploading new versions, which are not treated as merges until a later point.
In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a new file being loaded. With basic python programming, this process can be automated such that the CAD models change in realtime. OSE has not implemented this explicit realtime updating of CAD documents as of 2020 - but this is something that could be done relatively easily with a script.
Realtime Design and Merge Conflicts
Asynchronous design - people not working in realtime - is limited in its coordination aspect: people are not talking to one another. One advantage of realtime collaboration is that - by its nature - allows for higher coordination because people can talk to one another.
But version controls is still needed. And with people not working in realtime - merge conflicts are a definite issue to resolve. Whose version is accepted as the main branch?
In hardware, ultimately the builder is the arbiter. That is because the person who builds becomes the strongest stakeholder: they invest in materials, which cost money - in addition to their time, elbow grease, and risks of bodily injury or even death.
Because of this, Every Hardware Build is a Fork
Every builder must be respected. Their fork is useful as long as they document their work for others to learn from.
That every hardware build is a fork - is another way to consider that There is No Uniform Compiler in Hardware - by software analogy.
For Advanced Developers: Merge Reconciliation
The reconciliated of merges in CAD follows Test-Driven Design and the Second Toyota Paradox. Parts are not merged officially until they are tested, which requires extensive prototyping. Full testing may not occur until long after a design is made. But this does not mean that design must stop until further testing - as this would waste potentially valuable contributions of developers.
In order to not lock down any design - and thereby allow for parallel contributions - official merges are performed as late in the process as possible. This is due to the effort and expense of 'unit testing' in hardware, where testing cannot be done uniformly or immediately like it can be done in software.
OSE's process is to keep forks on individual contributors' work logs, or update the main branch. The product manager for a given product will make 'pull offers' rather than contributors making 'pull requests'. The distinction is that the 'pull offer' requires active intervention.
In hardware, however - there may be multiple branches in concurrent development. In fact, that is the only way it can be, as Every Hardware Build is a Fork.
