adamrg

(as author of original post)

Agreed. But GitHub did a lot more than just that - across the board it removed the barriers to collaboration (I used to run a few projects on SourceForge, and contribute to others; the ease of GitHub was like a breath of fresh air).

It got people excited and feeling free and able to collaborate.

...and so (I suspect) we're today less tolerant of unexpected barriers to collaboration. GitHub gets you hooked, then makes it extremely difficult to manage the "handover" part of a project (something that SF - for all its failings - handled pretty well).

The projects that die this way may well never have existed without GitHub in the first place - but that's not an excuse to just kill them off under a burden of maintenance crud.

(as the author of the original post)

In theory, yes. And I never used to worry about this. But over time, in practice, it's been a bigger problem than I think you're giving credit to.

e.g. ...

"Even if you have 200 people submitting patches, the odds are that most of them fall into two categories: people fixing the same bug, and people working on completely different sections of code. Neither is a substantial problem to merge."

IME ... in practice, this is a HUGE problem. Because every one of those developers fixes the bug in a slightly different way.

The longer time goes on without the original Author fixing it, the worse it gets. And the cost to them - or anyone! - of sifting through the "100 variations on bug fix #123" becomes greater and greater.

Usually, you want to cherrypick individual lines and characters from 5-10 of the best "solutions" to the bug.

If you'd avoided the "100 alternative fixes", then those "improved" solutions would have been built on the "basic" solutions - and merging would be easy.

But because you've got to this massively-forked scenario, all of the patches have been written independently and incompatibly.