4 ms·

In the age of git and hg, why is a fork such a big deal? Code can still flow fluidly between multiple forks of a project with almost no friction. Some amount

by mckoss 16y ago

In the age of git and hg, why is a fork such a big deal? Code can still flow fluidly between multiple forks of a project with almost no friction. Some amount of forking is probably healthy in the long run, allowing a different part of the community to take the lead and head in their own direction. In the extreme, if everyone works on an independent fork, and never merges, we lose the benefits of building "team-sized" projects. But that does not seem what is happening here.

wickedchicken 16y ago
The threat of developer and user drain is real. Forks can be good if a project is 'dead' or devs want to push it in a significantly different direction. But two forks that are similar and competing create subtle incompatibilities that force a developer to waste time doing something twice or, worse, add a feature/patch to only one branch and not the other. I would find it difficult to claim that code could flow "fluidily" between two forks -- forks are by definition different codebases and will always require extra work to cross-develop for.
danudey 16y ago
The friction isn't in the movement of code, it's in the movement of ideas and prioritization. Adding functionality, cleaning up the code, etc. When a project's contributors disagree substantially on how a project should be run, where the priorities should be, etc. then there can be a significant amount of friction just in day to day operations (like communicating about ideas on the mailing list). Perhaps some of the fixes from libav can be brought back into ffmpeg, but eventually people will want to standardize on one or the other, and if the libav folks are splitting off because they want improvement, revitalization, etc. and the old guard doesn't, then I suspect people will move to libav instead. Similar issues happened in the past with xorg (where XFree86 was mismanaged and eventually the community had enough and decided to fork it and fix it) and with KHTML/WebKit (where Apple forked it and made so many improvements to it that WebCore/JavaScriptCore have replaced KHTML in most (all?) projects (including Qt). That split wasn't a philosophical/managerial split, mind you, but the end result was the same.

by mckoss 16y ago

wickedchicken 16y ago

The threat of developer and user drain is real. Forks can be good if a project is 'dead' or devs want to push it in a significantly different direction. But two forks that are similar and competing create subtle incompatibilities that force a developer to waste time doing something twice or, worse, add a feature/patch to only one branch and not the other. I would find it difficult to claim that code could flow "fluidily" between two forks -- forks are by definition different codebases and will always require extra work to cross-develop for.

danudey 16y ago

The friction isn't in the movement of code, it's in the movement of ideas and prioritization. Adding functionality, cleaning up the code, etc. When a project's contributors disagree substantially on how a project should be run, where the priorities should be, etc. then there can be a significant amount of friction just in day to day operations (like communicating about ideas on the mailing list). Perhaps some of the fixes from libav can be brought back into ffmpeg, but eventually people will want to standardize on one or the other, and if the libav folks are splitting off because they want improvement, revitalization, etc. and the old guard doesn't, then I suspect people will move to libav instead. Similar issues happened in the past with xorg (where XFree86 was mismanaged and eventually the community had enough and decided to fork it and fix it) and with KHTML/WebKit (where Apple forked it and made so many improvements to it that WebCore/JavaScriptCore have replaced KHTML in most (all?) projects (including Qt). That split wasn't a philosophical/managerial split, mind you, but the end result was the same.