In [0], I shared some really basic thoughts about how this could be done by users of a particular VCS package, git. Two line summary:
You run `git announce [name] [tracker]` to tell a git tracker
that you've got your own fork. If you host your repository
in a public place, the tracker just checks your repo for
updates so other users can stay informed.
Alternatively, Fossil does "distributed version control and issues", but it's really just meant to be one central location for a particular project.
Thought I'd share. I'm on board with everything you're saying. There are clearly some issues as well, though. The biggest one I see is related to the "paradox of choice" -- when there are four forks all just one commit different from each other, how do you know which one(s) to use? This is why we usually just follow the leader (maintainer) and use the one true source. End users don't have the ability to quickly know which patches to accept and reject. Even a reputation system wouldn't necessarily provide clean signals, due to bandwagon type effects.
Unfortunately, I already have enough trouble picking between `iron` and `nickel` as a Rust web framework.
This is a rather abstract thought so I apologise in advance for it. I'm wondering what an open source world/tool that embraced that fluidity might mean for end users and core maintainers. Assume a tool called gitworld existed that did this. It might look like something where you can see which forks are best maintained. Community discussions can happen around all the forks as opposed to being against a repo by repo basis. So issues and PR's created could be applied by default to all forks and we might see which forks have closed these off? If I open an issue and a maintainer fixes it on her fork, the issue would show me that it's closed there and the final build exists there. It might also be really neat to have builds that become portable across forks so when someone forks my repo, as they work on it their code gets built and packaged automatically if I've done the necessary work to set those up. (not a very practical idea given resource constraints but it would be neat).
Like I said, it's an abstract thought but given the trend that we are seeing in open source management challenges, I'm wondering if it's time for a paradigm shift as it were in managing open source projects, communities, and expectations.