Hello everyone.
In my daily life I'm a (non-embedded) software developer, and use (and sometimes contribute to) many open-source projects (tools, libraries, etc).
I would say 99% of these open source are hosted on GitHub.
I was therefore surprised, when I found out that it's not as prevalent among open source hardware-related projects. I've seen multiple digital hobbyist projects which, while open source, don't seem to use any form of source version control systems (or, if they do, it's only privately). Releases are shared on the forums/boards as zip files, there is no well-defined process for submitting contributions.
I would like to know what the others think about the topic. Now I saw in another thread John D mention he really doesn't like GitHub, it's the first time I hear a person say that, and would be very interested to listen to the reasons.
For people familiar with programming but not used to source version control or platforms such as GitHub/GitLab/etc, I will give a brief overview below. People that are already familiar with the matter may skip to the last paragraph.
Source version control systems (VCS) are used to track changes in source code. As you (and any collaborators) work on a piece of software, VCS records the history of your changes. Later in time, you can find out when was some line of code added and by whom (with a comment left by the author that is supposed to shed light on the reason for the change). It's easy to revert changes that turned out to be not such a good idea. It's easy to create a new "branch" to experiment with things, then quickly switch back to the stable branch to make an urgent bugfix. Collaboration is improved as contributions from multiple authors (even to the same file) can be merged together with convenient tools. VCS are also quite efficient, because every time only the changes are stored, not full versions of your files.
Git, a software version control system (VCS), had originally been developed by Linus Torvalds for use in Linux kernel development. It is now the most commonly used VCS, used by most developers. Other well-known VCS are: RCS (very old), CVS (old), Subversion (svn), Mercurial (hg). I would guess no one uses RCS or CVS anymore, svn and hg has their followers, but they are in the minority.
A great thing about git is that it can function in a decentralized and server-less way (there is also a server). If you want, you can use all the features git provides without needing an internet connection. The entire history is stored locally. You could just backup your repo as a zip file, give a copy to your friend, then exchange contributions as patch files over e-mail. You can also set up your own git server locally or remotely, which is pretty easy. Or you can use a free git hosting provider, such as GitHub or GitLab, which is what most people do these days. There is no worry about one of these providers suddenly deciding to drop their free services, as you always have the full local copy (clone) of the repository including all the history, this can be easily moved to another provider if the need arises.
Services like GitHub or GitLab offer other useful tools besides git itself. These allow developers to conveniently manage things which are quite awkward and ad hoc when done via e-mails, forums and boards.
Issue tracker: users (or developers themselves) can create bug reports or feature requests. Those are handled similar to threads on a forum. When writing code to resolve an issue, a comment is put linking the code changes with the issue number. This way it's easy to see later how some issue was fixed, or which issue a given piece of code relates to.
Releases: it's easy to create a version of your software and make a release? (zip or tar.gz file). Releases are finished pieces of software (compiled, if applicable) to be distributed to end users who are not interested in the source code itself. These regular users (non-developers) just click the "Releases" link on your project page, and download the latest version, or an older one if needed. It's also easy to download a full copy of the repository as a zip file.
Collaboration: if you're a developer and you would like to try to make some modifications to the project, it's easy. I will use GitHub as an example, GitLab is almost the same. Register/login on GitHub, and open the project's page. Click "fork". This creates a fork (exact copy at the moment) of the project in your own account. Then, in your version of the project, click "clone", get the provided URL. For the next step you need to have git installed, or one of the GUI front-ends if you don't like command-line-only tools. Then you run "git clone URL" on the command line (or do the equivalent in your GUI front-end), with the URL being the clone link from earlier. Now you then have the project on your computer. Create a new branch (git branch) for your bugfix/feature, give it a meaningful name (e.g. "bugfix/10-wrong-button-color", where 10 is the number of the issue in the project's issue tracker). Make your changes, try them out. Let's say you're satisfied and want to contribute the changes back. Next step is committing the changes to your branch (git commit), this actually records the changes in the history. Each commit needs a message, usually mentioning the issue number and a short description of the changes, plus optionally a longer description. After that you push (git push) the branch to GitHub, this actually sends your changes to GitHub server. Open the project (your fork) webpage, and you should see your branch shown there. Click "pull request" and write a meaningful description. This will request the original project's developer to review/incorporate your changes. They can see the list of changes you've made (which files were modified, which lines removed and which lines added). They can leave comments on your code, if they find a mistake or something to improve. In that case you make more changes, commit and push again (no need to do anything else, the existing pull request is updated automatically). If the author is satisfied with the pull request, he merges your pull request, meaning your changes get incorporated in the original project.
When the original project has any changes of it's own, you incorporate it in your version yourself, by doing a git pull from the project's page (for that you have to add the original project's clone URL as a remote).
For me, this is the way to got for any open-source software. Collaboration usually makes software better, and it's great to have tools to make it easy to keep track of all the changes, bug reports and feature requests, without having to, for example, look for mentions of a topic on hundreds-pages-long forum threads where everything is mixed together.
Cheers
--Gene
