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.
Well, for one part. Whereby I was talking even more generally; any decentralized revision control system can do what I meant. But 'before GitHub' was a time where such decentralized systems where not really in wide use as they are today now (and GitHub has played an important role here).
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.
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.