I'm not convinced that Github itself is a net-win for the mainline projects -- without Github, your only options for long-term sustainability of a fork are to submit your patches to the project or to expend considerably more effort maintaining a local vendor branch.
If you need to add a feature to a project, that requirement isn't going to disappate just because Github does not exist -- you will almost certainly implement it regardless, and the path of least resistance will be submitting (and having it accepted) upstream.
With Github, it becomes much, much easier to create a fork, hack out what you need, and maintain that fork indefinitely in a form that can't be pulled back in without further polish/review that will likely never happen.
Uh, so? Have you ever worked anywhere that uses open source software? Often, these places have their own slightly-hacked version of everything. There is no chance the original project will ever see any of these changes; not because of legal restrictions to contributing or whatever, but because the fork-ers have no interest in publishing their changes. It would involve time and effort.
With Github, the path of least resistance is to publish your changes. If they are good, someone can clean them up and submit them properly. If they are not that good, then they can stay in the branch indefinitely.
Remember, all public contribution to open source is good. Wishing that volunteers trying to scratch their own itch would do it in a way more convenient for you is unrealistic.
(I watch my projects and pull in good branches from time to time. Sure, I have to change some stuff. But for 10 minutes of tweaking, I get days worth of work for free. So I love Github.)
I've noticed one of the few perfect divisions of coding labor in this process: the forker can more easily write the new feature with their subject knowledge, and the maintainer can more easily integrate the new feature with their domain knowledge. They each have their own independent motivations that result in the same goal by using their complimentary skills.
I've been on both sides of that trade, and it's always much nicer when I have a counterpart.
Remember, all public contribution to open source is good. Wishing that volunteers trying to scratch their own itch would do it in a way more convenient for you is unrealistic.
Perhaps I have unduly high standards for contributors, but I find that cleaning up other people's incomplete or unpolished code is often difficult, time consuming, and often takes longer than just writing the feature myself.
Whereas, if the contributor opened a dialog with me, I could help guide them towards something acceptable upstream with much less effort.
Sure you can have high standards for contributors. But if said contributor can't be bothered to cleanup his patch for upstream submission, then the absence of Github won't encourage him to suddenly cleanup his patch. He'd most likely keep his changes private. Remember, people are lazy and not going through the whole cleanup/submission route is definitely easier.
With Github at the very least you can see that those people exist and what they've been up to. To me this is still better than the alternative.
"Whereas, if the contributor opened a dialog with me, I could help guide them towards something acceptable upstream with much less effort."
Perhaps, but some people really aren't all that interested in such a dialog.
I confess to forking code in order to make changes that follow the principle of Make James Happy. I am often not interested in pushing anything back to the master branch, nor in coding things "just so" in order to fit into some project's coding standards. It's a matter of expediency.
(Yes, I do also submit patches to projects when I run into bugs I think I can fix. But here I'm referring to wanting a lib or app to take a different approach to things and to do things the right way, i.e. as James sees fit. :) )
In the past I would slurp down code as a tarball or maybe svn, and I'd go about my private alterations in secret. Now, I push my quirky changes back into the daylight. The upshot is that if anyone finds my changes useful they are free to take them and apply as they wish, with no cost to me.
It's a big improvement over the past, and observing that it still does not make things as easy as possible for the owners of the upstream projects is seeing the glass as half empty.
If you need to add a feature to a project, that requirement isn't going to disappate just because Github does not exist -- you will almost certainly implement it regardless, and the path of least resistance will be submitting (and having it accepted) upstream.
With Github, it becomes much, much easier to create a fork, hack out what you need, and maintain that fork indefinitely in a form that can't be pulled back in without further polish/review that will likely never happen.