I just committed a change to someone's library last week. It was like a lightbulb going off in my head - "Oh, so it's just this easy."
I wonder how much more difficult this was before Github.
I wonder how much more difficult this was before Github.
In the grand picture, github is just a nice frontend to patch that also replaces UUCP with something more modern.
Here are a few questions that might come up if you aren't using Github: "Is what I'm patching the canonical source?" "How do I set up my own VC for my patchset I'm maintaining?" "Am I sending my patch to the right person?"
That adds up to mental friction that distracts from actually writing the patch. With Github, you click a button and get your own repository. You click another button to inform the author (and! other people with their own forks, if you want). The author accepts your patch and the revision history has your name attached to it.
It makes it so easy that there is no excuse not to fix that tiny bug. Especially documentation bugs... you don't even need a git client to fix those!
This involves understanding of many things. Technology, the programming language and some CS areas. All of this most of the times a little out of reach of the ordinary day to day to programmer. The problem in simple words is 'The barrier to entry' to contributing most Perl/Python interpreter kind of projects is too high. You need to know a lot to do anything there.
I think that prevents most people from contributing even if they want to contribute.
Not much. Open source, and... well, software development in general is about people. Github makes it a bit easier, but the basic process is the same. Here are some programs developed before github:
Linux, Emacs, X11, Gnome, KDE, Apache, PHP, Tcl, Perl, Python, Ruby. They turned out ok and managed to garner their fair share of contributors.
Yes, they turned out okay, but that doesn't mean it wasn't much more difficult, right?
Github hosts mirrors of a few popular open-source projects, which is handy because they have much better source browsing than the alternatives.
Doing something new is totally different. What it takes to do nobody knows very clearly. This question has eluded humanity since its existence. You don't find Pyramids like the ones Giza in all ancient civilizations. You don't find literary works like that in India in any other ancient civilization. Sure the process to do anything in those societies may have been a catalyst.But starting something new totally depends on the quality of people who are there and in what many volumes they exist.
While git might have made contribution easier, it will not make number of new projects higher.
It wasn't really that more difficult. You either uploaded your patch into their bug tracker, or you sent it to them via email. Not a big deal at all. Many projects still work that way.
EDIT: Those who downvoted this comment, would you care to explain what's wrong with this statement? That would be very helpful. Thanks.
It just wasn't as good looking.
First you have to search for information about where to get the source and where to submit patches. Sometimes even this can be annoying.
Then systems like SVN makes it complicated when you want to work on it, try things out, etc., i.e. when you want to produce a patch-series where you could also revert some stuff. I.e. all non-trivial work. You need a system where you can make offline-commits.
Then there is some extra work to generate the patch, zip it and attach it to some report somewhere.
On GitHub, you just fork, work on it and make a pull request.
[1] http://en.wikipedia.org/wiki/Git_(software) [2] Of course, free software on github is hosted for free.
But another important part where I was indeed referring to GitHub: The portal allows easy forking on the site and you can easily make pull requests. That means you don't have to prepare a patch-queue or so which would require additional work. The project maintainer can actually easily look at your fork. The functionality GitHub provides makes it just simpler and more importantly also straight forward, i.e. you don't need to figure out first where to put your patch.