Hacker News Reader

Comment by ktamura | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com