Github vs Wiki

From Open Source Ecology
Jump to: navigation, search

Github is popular in software, but it is not designed for hardware mainly because every single replication, unless it's a stable version with defined production engineering and is currently being manufactured - is effectively a fork. See discussion at Every Build is a Fork. On memory issues alone, Github fails the basic requirement of documenting everything effectively outside of the main trunk.

Wikis are much more suited - because as databases, they can be reused easily.

Both Github (Gitlab) and wikis can be used. Distinct files can be put on Gitlab. But galleries - a menu to select from until a final commit - must be comprehensively visible and identifiable visually. For this purpose, Part Libraries on the wiki are indispensible.

The learning curve for Githib is larger than the wiki. If public product development is desired, it is easier to use wikis than Gitlab.

Nonetheless, Github is useful for 3D CAD, electronic design, software, CAM files - while the remaining 16 in the Development_Spreadsheet_Template#Simple_Template are best served by wikis, and remaining 36 of 40 of the Development_Spreadsheet_Template#Extended_Development_Template are best served by wikis. This makes Github useful for 10-20% of OSE workflow. However, this does not include the Enterprise aspect - such that realistically - Github may be about 5-10% of the OSE workflow.

In a nutshell - software is useful to be stored on Gitlab. CAD files are useful to be stored there. But wiki Galleries and Part Libraries are also needed because the development process for hardware is much different than software.

Another way to look at it: Gitlab can contain the necessary files. But it is difficult to embody a hardware development process, because the structure of Gitlab is deisigned for software development workflows. Thus, how can one use a software development workflow if one is developing hardware? One may argue that Gitlab also has wikis. Sure, but that does not fit with the existing wiki infrastructure of OSE - which is Mediawiki. Mediawiki is the most common wiki available.

OSE uses a self-hosted Mediawiki instance. This is for data security: we control the data fully. There is no risk of a third party platform going out of business.

OSE uses Mediawiki to embed all kinds of content. The OSE workflow involves the wiki, logs, embedded documents, part libraries, taxonomies. There is no compelling reason to use these features on Gitlab - because of the added complexity. Think of the wiki as a clean slate, which can be used to publish whatever you want - using HTML. You can do everything on Gitlab - but it's harder to do it.


  • ease of distribution
  • version control methods allow for many feature
    • Recovery of lost versions
    • tracking history
  • Ease of use
    • files are just dropped into a directory, and that is committed to the repository.
  • Wiki's become fragmented - it is very difficult to track what is the latest version of a project.
    • GIT is self organizing in some ways. Wiki organization requires standard operating procedures and diligence.


  • Does not allow realtime document editability, which is done in Google Docs in wiki
  • Does not use internal hypertext
  • MicroSoft owns GitHub now.
  • A CAD drawing and the BOM are not software code - it is hard to DIF and merge multiple commits from multiple people.
  • the document needs to be brought down from google docs and now is a local spreadsheet file
    • Really wondering how we resolve merges on multiple commits. with wiki file history, there is a continuous genealogy of uploads.