Other Software > Developer's Corner

Forking in Open Source Projects - Debate

<< < (3/4) > >>

f0dder:
Imho forking is a bad thing, and usually shows that a project is ill, whether it's because it's lead by too big egos, the codebase is a horrible mess, or whatever.

Forking means wasted effort, now there's suddenly (at least) two projects to maintain, but you basically still have the same pool of developers to work on the projects. Better to cooperate and not waste time. Yeah yeah, "you can always backport", but that's not always trivial, and it's more work than cooperating properly.

Lashiec:
Out of curiosity, does anyone know of any licenses that forbid forking and or distribution, but make the software sourcecode available for individual modification/examination?
-mouser (May 16, 2008, 07:22 PM)
--- End quote ---

A custom license, like this one

Imho forking is a bad thing, and usually shows that a project is ill, whether it's because it's lead by too big egos, the codebase is a horrible mess, or whatever.
-f0dder (May 17, 2008, 04:59 AM)
--- End quote ---

Well, in those cases a fork is more than recommendable, I think :)

I don't know if Funpidgin can be considered a 'fork' in the true sense of the word, after looking at the changes introduced in the program, this looks more like a 'mod' than a fork. Of course, if the program is further developed like their authors claim, I guess that later you can call it a 'fork', but I suspect that either it won't be, or it will be backported into Pidgin, after a time of discussion.

Forking can be a bad or a good thing, that depends on a lot of aspects. Examples of a bad fork are Compiz, which spined off Beryl. Beryl was a more feature-rich version of Compiz, but was also licensed under the GPL, unlike Compiz, which used BSD, that meant Compiz could not take code from Beryl, but the other way around was possible. Fortunately, as you may know, Beryl was abandoned and renamed as Compiz Fusion, which is expanded version of Compiz, but without requiring a separate codebase (thanks to plugins and external tools).

Other bad examples are ffdshow, Media Player Classic and Visual Boy Advance. After Milan Cutka, gabest and Forgotten, respectively, abandoned the development of these three projects (well, gabest claims he will come back to MPC at some point), a lot of forks appeared, and clearly it was a f****** mess, not only for developers (and, in the two first cases, codec packs authors), but also for users, as it confused the hell out of them (which is the best? which one should I choose?). After some time, various authors stepped up and decided to merge parts of the different projects and create newer ones with the resulting codebase (ffdshow tryouts, the two builds of MPC maintained by the guys at Doom9, and VBA-M), which finally injected some sanity to the whole situation (the Visual Boy Advance was a particular sickening one, because most forks focused on feature bloat, without particularly improving emulation accuracy).

But don't fear, there are good examples as well, WebKit being the most prominent one. As you may know, WebKit was up to not so long ago, the Apple-forked codebase of KHTML. If we look at the situation back then and right now, clearly the forking was extremely beneficial for everyone involved, and for many people more. A rendering engine used by an relatively obscure web browser is now the darling of software development companies, being used in Safari, OmniWeb, Konqueror, the iPhone, and Google's Android platform, while is also being introduced in Qt 4.4 as the default HTML engine, and effectively replacing KHTML in KDE 4. Hell, even the Epiphany team (another example of forking) replaced Gecko after using it during years with WebKit.

Other examples are the particular mods of certain Miranda plugins, that always implement newer and more advanced features compared with the original plugins, and end up being backported into the main plugin. Actually, the developers seem to like this, as it means the plugin is being improved in ways the original authors would have not followed (lack of time, lack of interest, etc.)

So, like everything in life there's no single answer, and only time will tell if Funpidgin was a good idea, or just another IceWeasel situation. And which path of the four outlined by Jeff Atwood will take.

*PHEW* :P

f0dder:
Other examples are the particular mods of certain Miranda plugins, that always implement newer and more advanced features compared with the original plugins, and end up being backported into the main plugin. Actually, the developers seem to like this, as it means the plugin is being improved in ways the original authors would have not followed (lack of time, lack of interest, etc.)
--- End quote ---
Thing is, this shouldn't be done as a fork, but by submitting patches to the original author, or (in case he's inactive), taking ownership of the project. Forks confuse people, and waste time.

Lashiec:
Yeah, actually the developer of TabSRMM said that in the future he would like to see all mods submitted as patches so he can include them in the main plugin, and effectively get more people collaborating with the project. The Miranda plugin ecosystem is quite particular, as practically all plugins are developed by a single person, and sometimes they maintain various plugins (in this case, TabSRMM and Clist Nicer+, which are everything but small)

mouser:
Just to clarify my position: I don't believe that forks are always bad -- I can think of cases where a coder or subgroup wants some substantial stuff added that everyone agrees should not be part of the original project, and almost everyone agrees that it would be more fruitful for it to fork off into two projects with separate aims.

So I'm not against forking per se, I just feel like the potential of forking to dilute the pool of coders working on the project is high.  And that there is a substantial risk of major headaches for maintainers and users if someone decides to fork a project for their own selfish reasons and decides it's in their self interest to promote their fork and compete with the original active project for resources and attention.  I understand this is an unlikely/worst case, but then again so is the prospect of the original maintainer refusing to incorporate reasonable code.

That's why i was considering a license which gives the current maintainer of an active project some control over when and hot to allow forks.  However, I do recognize that in terms of a free software philosophy, this is problematic because it means closing the safety valve that is always available otherwise with forking.  So I'm not sure what the best solution is..

Navigation

[0] Message Index

[#] Next page

[*] Previous page