[davidw]

+1

An open source project is a human thing. Github forks and stuff are neat, but to have a real project, some coordination is necessary, and I really wish that Github would provide more tools to encourage this. It's really dismaying to see some project with 2343232 forks, many of which are newer than the 'main' one, and see little to no coordination between them.

[strumptrumpet]

I believe the best tool Github could provide to encourage this would be to make forks subsidiary to the project they're forked from.

[davidw]

The solution would involve some kind of communication and perhaps a way of electing a 'leader'. I don't claim that it's a particularly easy problem to solve, but it seems to have been done when people just used a mailing list and cvs, so it is possible...

[strumptrumpet]

> I don't claim that it's a particularly easy problem to solve, but it seems to have been done when people just used a mailing list and cvs, so it is possible...

It worked back when we had a mailing list, CVS, and a web page because a single individual or set of individuals owned the top-level project infrastructure associated with the name in question.

Github broke that model by making forks largely non-subsidiary to the projects they fork. They exist at the same namespace, they have independent bug tracking, wikis, and author information.

This breaks the social economy of contribution that previously existed; even if you choose to not participate in Github, your project will be forked hundreds of times via published Github-based mirrors that look like every other top-level copy of the project.

[mamcx]

Yes, I have the readme be the same everywhere... uff!

I think that is important a distinction between a full fork and a "I do a single fix" fork... but how?