In my view, successful (and hence viable) open source projects tend to have<p>1. Centralized decision-making<p>2. Distributed contributions<p>While forking is important and necessary to experiment/test/prototype and iterate on various ideas, forking of a community is absolutely deadly. Look no further than Emacs/XEmacs or Node.js/io.js. It's very, very important that the ultimate decision making authority is concentrated on a few people with sound judgment (Often the creators, but not always).<p>On the other hand, development/contributions should be absolutely distributed: it accelerates development and makes it much easier for people to contribute to open source projects.<p>In fact, understanding this subtle difference between decision-making and development is what made GitHub successful: git was already a great tool for developing in the open. GitHub built a great platform for making decisions on top of it.
Maybe another improvement would be some metadata field on the fork to indicate <i>why this fork was created</i>. Are you forking because you want a copy in your namespace? Are you forking to add new functionality? To support different versions? Did you misclick star? Did GitHub create one for you without you even knowing because you wanted to make a quick PR to the README?<p>Sometimes this info is in the README, but it would be nice to see that surfaced in the Forks graph.
Fork discovery is a serious issue in cordova mobile plugins world. I think people go native at one point and abandon their repos :)<p>Ad article, another point is that someone might have a manually created fork, without the link on github, or they asked GH support to unlink the two repos (because they want to be perceived important, not just a fork etc). Not sure how to handle that case well and if GH will invest time in that.<p>For the discovery of forks: I think an interesting feature could be some heuristic like: IF no commits in N months && there is a fork with at least M stars and K commits forward THEN list top 3 forks on top of repo's readme, on a distinct background (say, yellow) with a message: Hey, you might be also interested in these forks: A, B, C.<p>Having said that, I think it's a very low prio for GH probably.
All open source projects are just forks all the way down. The hierarchy and "top" are just ways to represent them, they don't have inherent meaning. Remember: GitHub isn't the authority on git.
Agreeing with the premises, let's call this what it is - a recommendation/curation problem, which a kind of thing that a trusted third-party usually does. Seems like it would fit as a Community Explorer blog/engine, as a separate presence.<p>Except we already have powerful personalities in the development space who already share their opinions and value systems - this is a natural extension of that. After all, a lot of choice of what is the "right" fork or even the "right" tool to begin with gets back to subjective developer experience and intuitive tech preferences. And that's something that a platform like GitHub should stay neutral to.
> But it doesn't make sense for the original repo to be the only repo which can ever be canonical.<p>This is a red herring. The problem that's a lot easier to solve and will benefit the community just as much is better discovery of useful forks.<p>The current interface that GitHub gives for discovering forks is awful when it comes to this.<p>P.S. Those two diagrams do a poor job of explaining the problem, they're the same diagram.