I have contributed to dozens of other people's repos. As a rule, I make a change, share it back, but run my own fork. Later if they merge my change, great, I can point back at upstream. But it's no big deal to have your own version -- that's part of the strength of open source.
People get bent out of shape over whether upstream will merge their change, and I've heard people complain that they "wasted" their time making a change that's not accepted. But that's silly -- if you wanted the code, it wasn't a waste. Run it.
Git also makes it really easy to maintain your own changeset over time even as you incorporate upstream changes. It's pretty much designed with that use case specifically in mind.
It's wonderful when project maintainers are responsive and work to incorporate every good-faith improvement. That's the ideal. But it's also fine to fork when they simply can't or won't keep up.
On many occasions I have also merged other people's lingering/rejected pull requests into my own fork. The project maintainer doesn't have to be the final arbiter.
Hasn't it always been the case that you need permission from the maintainer to get your code included in the official version? But you can still fork your own version at will, and github makes that a one-click process, which seems considerably better for distributed responsibility than the old CVS / SVN style...
> algorithms dynamically find us the optimal code for doing X from around the internet without X being a single privileged master branch temple on GitHub.
Sounds more like a publicly editable wiki for snippets than open-source project hosting
Likely will never happen.
For example:
~Counting sort is awesome with low range on inputs.
~Quicksort on user inputs is an attack vector because of O(n^2) worse case run time (CPU consumption attacks).
~Merge Sort is nice on user inputs b/c of its static runtime.
Without understanding the context of when and why sort is called, and what sort will be sorting you can't make an informed decision of what algorithm to use. A lot of this nuance escapes even very senior developers.
I imagine that in the future we will have a "Google for code", where algorithms dynamically find us the optimal code for doing X from around the internet without X being a single privileged master branch temple on GitHub.