4 ms·

1. One account for manifesting your chosen identity, which you likely already have. You also have an email address, so. You need an email address to get a GitH

1. One account for manifesting your chosen identity, which you likely already have. You also have an email address, so. You need an email address to get a GitHub account, so technically it's harder to set up GitHub. 2. One common way of getting the source code and sending diffs/patches (read: PRs). This is built into git. Don't need GitHub for either.

aktau 8y ago
It looks like you think that older approaches to open-source collaboration (like many of the GNU projects are using) are more or less as user-friendly as GitHub. I don't have the data to prove that they aren't, just an intuition. Perhaps the last argument I have is that I've heard a number of times about moving a project to GitHub (for example: the Go language or Vim the editor), but decidedly less often one hears of projects moving away from GitHub towards older forms (such as the wonderfully documented https://gcc.gnu.org/contribute.html https://gcc.gnu.org/contribute.html). Despite the great documentation, I'm somehow not drawn to hacking on it to fix a small glitch, due to the overhead that entails. Mind, some of that overhead would be incurred just once, as it is general to the mailing list approach to collaboration. That, I believe, is another advantage of a project being on GitHub: for almost all projects there's a standard way of sending your patch: make a pull request. About your counterpoints: 1. True. I was thinking of the bug trackers many mailing-list oriented projects have, which often require creating accounts just to file a bug. 2. I was more referring to things like (1) where to find the clone URL and (2) how to send a patch (the make a PR button is always the same). Removing friction (even small frictions) will enable fishing for the long tail of small fixes. On the other side, I do not believe large contributions are greatly affected by the differences between these systems.

aktau 8y ago

It looks like you think that older approaches to open-source collaboration (like many of the GNU projects are using) are more or less as user-friendly as GitHub. I don't have the data to prove that they aren't, just an intuition. Perhaps the last argument I have is that I've heard a number of times about moving a project to GitHub (for example: the Go language or Vim the editor), but decidedly less often one hears of projects moving away from GitHub towards older forms (such as the wonderfully documented https://gcc.gnu.org/contribute.html https://gcc.gnu.org/contribute.html). Despite the great documentation, I'm somehow not drawn to hacking on it to fix a small glitch, due to the overhead that entails. Mind, some of that overhead would be incurred just once, as it is general to the mailing list approach to collaboration. That, I believe, is another advantage of a project being on GitHub: for almost all projects there's a standard way of sending your patch: make a pull request. About your counterpoints: 1. True. I was thinking of the bug trackers many mailing-list oriented projects have, which often require creating accounts just to file a bug. 2. I was more referring to things like (1) where to find the clone URL and (2) how to send a patch (the make a PR button is always the same). Removing friction (even small frictions) will enable fishing for the long tail of small fixes. On the other side, I do not believe large contributions are greatly affected by the differences between these systems.