
Thought Experiment: GitHub Community View - dyoder
https://www.pandastrike.com/posts/20150610-thought-experiment-github-community-view
======
ktamura
In my view, successful (and hence viable) open source projects tend to have

1\. Centralized decision-making

2\. Distributed contributions

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).

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.

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.

~~~
tessierashpool
caveat, I wrote the "thought experiment" post, so this is not unbiased, but
how "deadly" was the Node.js/io.js fork, really? io.js merged back into Node
and basically became the canonical implementation.

My blog post is about situations where the community's _already_ disunified
anyway, so the remark about "forking a community is deadly" misses my main
point -- but even if that weren't the case, wouldn't the Node/io situation be
the best example that forking a community sometimes turns out great?

~~~
alexwebb2
> how "deadly" was the Node.js/io.js fork, really?

It wasn't, ultimately - it just served as a reality check for the Node
maintainers at the time and helped spur some much-needed changes to the way
the project was being managed.

The fact that there can only be one _truly_ canonical repo forced the
disaffected contributors to splinter off into an entirely new project with a
different name. If that wasn't the case, and forks were truly first-class
repos, then they may have opted for that instead - and we'd have had "node"
and "other node" instead. Personally, I think that would have been much
muddier.

The node/io.js split and eventual reunion is a fantastic example of why the
system as it stands currently - which strongly encourages schisms to be
explicit and branded distinctly - is in fact a very practical model.

~~~
tessierashpool
> _The node /io.js split and eventual reunion is a fantastic example of why
> the system as it stands currently - which strongly encourages schisms to be
> explicit and branded distinctly - is in fact a very practical model._

Well, maybe, for large projects, where there's a defined community with lots
of visibility. Not for small projects with no hype spotlight shining on them.

And even then, it didn't work out that beautifully for Express.js, either,
which was not exactly obscure.

------
swanson
Maybe another improvement would be some metadata field on the fork to indicate
_why this fork was created_. 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?

Sometimes this info is in the README, but it would be nice to see that
surfaced in the Forks graph.

------
jakub_g
Fork discovery is a serious issue in cordova mobile plugins world. I think
people go native at one point and abandon their repos :)

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.

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.

Having said that, I think it's a very low prio for GH probably.

~~~
coderzach
YES! I almost always find myself digging through the network graph of cordova
plugins hoping to find one that works.

------
cthulhujr
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.

~~~
JorgeGT
Indeed, from a graph theory POV the "top" and "canonical" graphs are exactly
the same graph, the difference is psychological at best.

------
mmatants
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.

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.

~~~
jakub_g
Sometimes you have a pretty niche tool or plugin with a small number of stars
(few hundred) and just a few committers. The community of that tool is
typically too small in that case to have vocal personalities recommending
forks.

------
reledi
> But it doesn't make sense for the original repo to be the only repo which
> can ever be canonical.

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.

The current interface that GitHub gives for discovering forks is awful when it
comes to this.

P.S. Those two diagrams do a poor job of explaining the problem, they're the
same diagram.

