5 ms·

In my view, successful (and hence viable) open source projects tend to have 1. Centralized decision-making 2. Distributed contributions While forking is impo

by ktamura 11y ago

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.

deleted 11y ago
[deleted]
Karunamon 11y ago
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 http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
tessierashpool 11y ago
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 11y ago
  > 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 11y ago
    > 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.
madeofpalk 11y ago
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.

by ktamura 11y ago

deleted 11y ago

[deleted]

Karunamon 11y ago

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 http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

tessierashpool 11y ago

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 11y ago
> 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 11y ago
  > 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.

madeofpalk 11y ago

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.