Thought Experiment: GitHub Community View | Hacker News Reader

Thought Experiment: GitHub Community View

pandastrike.com

52 pointsdyoder14 comments

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.

forking of a community is absolutely deadly

Could you expand on this a bit? I imagine it depends on who "deadly" applies to, but forking is just one of the ways centralized decision makers who are, erm.. not making very good decisions can be worked around.

Look at what happened to ffmepg/libav - by any analysis, the fork resulted in better software:

http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

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?

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

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

The Node.js/io.js fork was amazingly beneficial for everyone, I think.

Those that just didn't care (at the time of the fork) stayed on Node v0.12.

Those that wanted latest and greatest (ahem self-induced 'javascript fatigue') got to 'upgrade' to io.js

Then 6 months later that Node.js devs came to their senses, realised they've dropped the ball, and merged in io.js and now have a proper release cycle. I never ran into any downsides - magically one day I got an update to Node that had the new ES6 features.

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.

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.

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

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.

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

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.

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.

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

Reply on news.ycombinator.com