Can there be a GitHub for hardware?
Supporting collaboration in your project depends in particular on coordination, task division, publicity, communication, conflict resolution and documentation. Since it is the widely held assumption that GitHub fulfills most of these aspects for open source software, this leads some to the conclusion that there simply needs to be a GitHub for hardware. The particular focus of this wiki is the collaborative development of physical products in open source communities. In this regard the question naturally arises how more collaboration can be achieved and what can be transferred from the process conception of GitHub.
The open source hardware statement of principles 1.0 refers to the four core principles of the open source concept: the right for anyone to use, to study, to modify and to distribute the design of objects. Platforms like GrabCAD and GitHub can support the open design projects to meet these openness criteria by providing the right set of documentation and collaboration tools. On this wiki page we will focus on the usage of GitHub since it is very popular and mature in its functions. It should be noted at this point that although GitHub excels in the collaborative software development field, it does not satisfy all the needs of open design product developer. For example it is not possible to work on CAD files (only 3D printing STL files can be visualized) or there are no advanced project management functions to structure work packages (the latter can be bypassed when using GitHub’s API and cloud-based team collaboration tools like Trello). Furthermore even though GitHub greatly improved the development of open source software, it is by itself ironically not open source (although it is based on the open source program Git). If you are fond of FOSS and are looking for an appropriate alternative, check out the community version of GitLab which is a platform that provides you with similar features as GitHub.
Overview GitHub & Git
GitHub is a web-based platform where developers can share source code, work collaboratively on it and connect to other developers. When several people are working together on the same piece of software, it is important to keep track of all the file modifications. Thus collaborative projects need a revision control system that records every change with a timestamp and allows changes to be compared, restored and merged. GitHub is basically a revision control system with added functionality (see further below). The software that runs at the heart of GitHub is Git, a command line tool originally created by Linus Torvalds, the principal developer of the Linux kernel.
Basically there are two types of version control systems. In centralized version control there is a single, central repository, on which clients synchronize. In distributed version control, every participant has its own repository. A repository is a folder inside which you are going to store every piece of your code. In recent years, there has been a switch to distributed version control for projects because in practice it supports collaboration so well. Git itself has been designed as a distributed version control system. Conflicting versions from different authors co-exist in parallel and can be freely modified. If needed at some point the different versions can easily be merged together in one common file. After installing Git on a machine, a local repository can be set up. However in order to enable efficient collaborative work, the local Git repositories must be accessible by the web. This is where GitHub comes into play. GitHub is the most prominent cloud-based publishing tool and hosting platform built on Git. Its main use is to provide an online repository place and for this purpose it is the platform of choice for the majority of software engineers worldwide.
How to use GitHub
To use GitHub you first sign up and create an online repository. That way the online living space of the project is set up. The real work of coding will still be done on the local computer where Git is used. On the local computer you create a directory for the project and in it a Git repository. Now you can connect your local repository with your freshly created GitHub repository. By default your online GitHub repository can be seen, opened and downloaded by every user unless you pay a monthly fee in order to get a private repository not to be shared publicly. Now everything is ready to work on a collaborative software project. Imagine you worked on a project by yourself for some months and thus lay a comfortable bases which you feel would now be best developed further in a collaborative way. Your source code is well commented and freely accessible through GitHub and you want to promote collaborative development. How can others contribute to your code in GitHub? Contributors must have a (free) account on GitHub. They go on your GitHub page, select your repository and fork it. This will make a copy of the repository to their GitHub account. At this point, they repeat what you have already done: create a local Git repository and connect it to their GitHub repository.GitHub’s most common collaborative development model can be described as fork & pull model (or pull-based development model). In this model, developers create copies of the original repository (‘forks’) which are then used as isolated workspaces. They can send a pull-request to a maintainer of the original repository to indicate that they made changes to their copies that can be integrated back to the initial repository. The maintainer can then decide to merge these changes. So to resume our scenario, your contributors can work on their forks and send you pull-requests if they want to contribute back to your project.
In addition to hosting repositories, GitHub provides you with other features such as:
- Issue tracking system
- Personal websites
- Personal profiles
- 3D File Viewer for STL files
- Network graphs
- Contributor statistics
This overview shows that right after being a capable hosting service for source code, GitHub can moreover be described as a social network that is indeed widely used by developers (and even headhunters). These two aspects combined are what is at the core of GitHub’s success and global spread.
Open design projects using GitHub
Several open design projects use GitHub to collaborate, document and share their work. Just google for GitHub and for example RepRap Mendel, Apertus Axiom, OpenPCR, Ultimaker 2, OpenROV and Xcarve. You can easily explore their public repositories.
- Repository with powerful version control which enables you at any time to go back to previous versions, to merge different files from different users, to understand when, where and why a file was modified
- Very structured software development process and thus efficient way of following common workflows (comprising cloning, branching, staging, committing and pushing in Git)
- Easy collaboration whereby anyone can contribute to the project on GitHub (through forking and sending pull requests)
- Higher visibility of your project as parts of it are hosted publicly on a very active social network/platform.
- All these additional benefits (free webpages and wikis) come at no cost
- Great opportunities for extension through more than one hundred third-party applications which are connected with GitHub’s API (https://github.com/integrations)
- Last but not least free cloud space that can be accessed and copied by everyone
== Limits ==
- GitHub is in practice mainly used for code (it was initially designed as a web-based version control system for software). For instance inspired by GitHub, Onshape allows branching and merging of CAD files.
- GitHub allows you to define teams (with read, write or admin permissions), create checklists and open issues but if you need more project management to define project phases, work packages, roadmaps or milestones reporting, you will have to use other applications like Trello or OpenProject.
Contributions of GitHub-style of workflow for product development
Since GitHub has empowered the open source software development so well that some people speak of the GitHub revolution, among open design developers the desire arises to have a GitHub for physical things like hardware or mechanical devices. Instead of focusing on a future yet unborn platform, why not draw the attention to what actually made the success of open source projects using GitHub? In short it simplified collaboration trough distributed version control and the pull-based development model and providing attractive social benefits.
However, the main contribution of OSS could be described as the capacity to absorb or be absorbed by another project which provides new channels of communication and knowledge transfer/creation. This is especially facilitated once a project is completely owned by the collective of a community and not individual founders. Because at that point the community may just have to jump on board.
Further it cannot be omitted that open design collaboration is likely more complex than in the software field. What about development costs? Prototypes have to be built and cost easily thousands of euros. In some cases this can be perhaps bypassed when the construction is modularized and only parts of it need to be replicated to work productively on it. This leads to another need: some team members will have to meet up in real to build and see the prototypes. The initial question if there can be a GitHub for open design is also somewhat misleading since it does not differentiate between all the huge differences there are in developing (electronical) hardware or mechanical compounds (out of steel, plastic, carbon, etc.). Is it possible (and useful) that a single platform provides the tools to share the project data, to get to know other developers, to manage the project and to create CAD- / STL files and schematics, etc.?
So to resume for the moment there is no comparable and established workflow in open design. And it seems that not a single platform can make the whole development process fluid but that several different tools are needed. The real challenge is to organize an effective process which is in its nature more complex than in the software field. Developers should ask themselves how they can simplify and promote collaboration to their projects which requires first and foremost complete process transparency and integration capacity. What about task division, coordination, communication and awareness? Can the design be modularized? Can you link your project with another project using some common interface? To sum it up: is collaboration made easy or is there something that prevents others to contribute to your project? Open Source Ecology addresses the needs and challenges of the open design product development process in a worthwhile article: http://opensourceecology.org/open-source-hardware-development-method/ .