Best case, one of the forks clearly emerges as "the" new primary repo and everybody shifts their focus there. But that doesn't always happen. It's a real problem with the fork-centric model that Github promotes. Of course, one could argue that this state of affairs is still better than the "old way" where forking a project was a very heavyweight process and rarely happened at all. But that doesn't mean the current model couldn't be improved further.
Is this Citizenship idea the right way? I don't know, but - at worst - it's a good discussion to have.
Isn't this the real issue that should be fixed then? Some way when you form a repo, you get notice of all the forks and PR's of the original repo, giving you the possibility to merge everyone's work and become the defacto upstream.
IMO, yes. Providing some kind of mechanism to make it easier to gain cohesion between all the disparate forks is definitely at least part of the answer. I haven't spent a lot of time thinking about this, though, and I don't pretend to have any real concrete suggestion in mind.
Yes, with power comes responsibility. If you don't want the responsibility, don't ask for the power.
>>> but there's no real cohesion or interaction between all these isolated forks.
If there is enough people interested in the project, that can find one who wants to take maintainership. If they can't, the project doesn't have that much value for them.
>>>> It's a real problem with the fork-centric model that Github promotes.
I don't see a problem here. If there's a strong community, fork changes naturally gravitate back there due to the advantages of community size. If there isn't, making random people be able to mess with the code base is not going to fix it.
> Is this Citizenship idea the right way? I don't know, but - at worst - it's a good discussion to have.
Completely agree.
Forks and forks of forks and forks of forks of forks have the effect of diffusing effort, where the main project has the effect of focusing effort.
Still, something like Google Code "feels" like it is more "project centric" than "source code centric" if you get what I mean. There's specific places to do things like linking in Google Groups or mailing lists, project blog, Twitter account, etc. And the way it's organized just makes it feel like more of a "project home".
Compare:
https://github.com/fogbeam/Quoddy
with
http://code.google.com/p/quoddy/
Anyway, what I'm getting at is, if GitHub did more to foster a cohesive community around projects, I think it would help with the "abandoned project" thing, since there would be more of a sense of "go here and discuss whose repo is going to become the new mainline" etc.
If I click on the source tab, I want to see the source. GitHub gets this right. Google just presents you with boilerplate garbage. No, I don't want to use Subversion. Ever again. Don't even bring it up.
The real problem is how user unfriendly Google Code is, where things are compartmentalized arbitrarily and an extraordinary amount of clicking is required to get the information you need.
The "groups" feature of that is virtually useless in my opinion. I can't stand typical web forums with their chronological ordering of posts, and even those that are threaded but don't show the thread on one page are infuriating, where many "mailing list" viewers are terrible offenders in this case. You may sift through half a dozen replies only to find the problem is still unresolved.
Stack Overflow and GitHub are examples of how to organize the user experience better. Both could improve further, but Google Code seems like a huge regression in most areas.
Great, so there's one extra click to get to it. And even that is only because we consciously chose to use Google Code to serve as the "project/community home" because GitHub is lousy at serving as that. Of course, all this was setup before GitHub Pages, IIRC. We could look into scrapping the Google Code presence now, probably, but it's a fairly low priority relative to about a bazillion other things.
GitHub gets this right. Google just presents you with boilerplate garbage.
To be fair to Google Code, they do support git, and keeping a reference to Subversion was a conscious decision that we made. You may hate Subversion with a passion, but not everybody does.
Anyway, the point is, with GitHub, by default, ALL you get is "the source tab". But there's a lot more to a project than just source code.
... GitHub are examples of how to organize the user experience better.
GitHub may be better from strictly a "how to get my hands on the source" perspective, but I think it's very weak from the "How do I get an overview of the project and the community as a whole" perspective.