Simon Wistow worries that the distributed nature of git results in fragmented software projects:
That model works well for Linux. Maybe. I'll presume it does. Git eases the pain points expressed by Andrew Morton, the maintainer of the -mm tree, in this message entitled "This Just Isn't Working Any More"
In short, it makes siloing easier.
My immediate reaction to reading his post was to think of the old saying ‹‹Guns don't kill people, people kill people››. In fact, my experiences with forks so far has been two cases of forking repos on github, and doing a pull request to the author when my fixes were fit to be included in the main distribution. In both cases the authors included my changes in their versions.
Just because there exists a lot of works-in-progress doesn't mean that they represent different authoritative versions of a given module. The situation for the rails OAuth plugin might be a bit muddled, but thanks to github's excellent network map, it's easy to track all of the 12 forks on github (substantiality less than 27), out of which most seems to have merged into a new mainline.
It is clear that this project suffers from a inactive maintainer, but I believe that Git forks has lowered the barrier to contributing substantially, thus ensuring vitality for open source software projects. Our own Catalyst OAuth support, which resides in SVN is still non-working, despite several promises from people to look into it. These people might have working support in their local applications, but if that is the case, I'm unable to get to them or merge it into the started efforts in Catalyst SVN.
To summarize, Git lowers the barrier to contribution. Building or avoiding silos is up to the software maintainers, and giving support for patched versions is madness any way we look at it. Just the same way as developers are on their own when they use development versions of software, they can't expect support for forked versions of that software either. If you live on the bleeding edge, you are going to bleed a little.