topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 11:10 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Forking in Open Source Projects - Debate  (Read 16403 times)

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Forking in Open Source Projects - Debate
« on: May 16, 2008, 11:23 AM »
Dare we say that the Coding Horror blog has been a little weak lately.. But today's blog essay was on a subject that I have been thinking about recently.  I was talking to DC member Gothi[c] about collaborating on an open source project, and i raised the possibility of using a custom license that would discourage or disallow forking.  I'm not a big fan of forking for a variety of reasons.

So I thought we might use this as a jumping off point to talk about the issue of "forking":

Forking is incredibly difficult to pull off. It is a painful, but necessary part of the evolution of open source software. Just as in real evolution, I suspect that most forks die in vast, nameless numbers, before they become strong enough to engender any forked progeny of their own. Forking is the absolute bedrock of open source software -- but it is also not a path to be chosen lightly.

« Last Edit: May 16, 2008, 11:54 AM by mouser »

Deozaan

  • Charter Member
  • Joined in 2006
  • ***
  • Points: 1
  • Posts: 9,747
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #1 on: May 16, 2008, 05:37 PM »
So you quoted Coding Horror's opinion but neglected to explain your own. Let's hear what you have to say about it, mouser.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #2 on: May 16, 2008, 05:56 PM »
Well my life experience has led me to be skeptical about *totally* decentralized community projects.  I think that most of the time you need some kind of loose hierarchy, someone responsible for making ultimate decisions, or riding heard, or just making sure deadlines are met and quality control is reasonable, etc.

I'm also an extremely non-competitive person, and i hate the idea of different groups working on the same project but at cross-purposes and on incompatible solutions.  I understand the motivation for forking off a project, but in practice it seems to me like an absolute last resort -- much better that the people find a way to come together and team up and pool their efforts.  To me forking seems like an admission of failure and discord, and promises to split apart teams and developers.

Maybe if you have an abundance of developers and want to take the product in two completely different directions it would make a little more sense, but it just breaks my heart a little to think of the loss of productivity that would have been gained if the teams could have worked together on a common project.

The other issue i have has to do with giving due credit and control to the founders of a project.  The original issue of forking came up when i was telling gothi[c] about an idea i was playing around with about me doing more open source software for DC, and thinking about ways that could be done while still encouraging (or at least not discouraging donations).  One issue that troubles me with open source is that idea that someone could spent 10 years on a project, pour their heart into it, and then have some greedy person come by and add a new logo to it and fork off a new project and try to capture the user base with marketing money, etc.

So i was thinking about the possibility of an open source license that gave more control to the original coder(s). Like letting anyone modify the code for their own personal use, but giving the original coder(s) final say whether a given fork was allowed, final say about whether other distribution methods were allowed, etc., and various other things that would just in general give the author more control over the *public* evolution of the software.

Eóin

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 1,401
    • View Profile
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #3 on: May 16, 2008, 07:00 PM »
Mouser I can see where you are coming from but I think you should be careful using the term open source because the extra restrictions you're suggesting very much go against the spirit of open source software. If others cannot redistribute freely then it isn't really open source.

That said I suppose I take the stance that if you are going down the open source road then go there properly and BSD/MIT your code. I don't even like GPL. LGPL is ok though :)

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #4 on: May 16, 2008, 07:21 PM »
you're right, i suppose the restrictions i was/am considering are not compliant with the Open Source Initiative definition.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #5 on: May 16, 2008, 07:22 PM »
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?

Deozaan

  • Charter Member
  • Joined in 2006
  • ***
  • Points: 1
  • Posts: 9,747
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #6 on: May 16, 2008, 08:05 PM »
Since I'm not experienced with doing anything with Open Source Software besides downloading it and using it, I can't really help much with licenses and those kinds of things, but what mouser describes sounds very reasonable to me, although it is clearly against a number of the points described in the Open Source Initiative definition.

Point #4 seems to be the point that agrees most with what mouser is saying, as it could require any forks to be installed as unofficial patches on to the pristine base code of the original author(s):

4. Integrity of The Author's Source Code

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations.

Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source.
(emphasis added)

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #7 on: May 16, 2008, 08:16 PM »
Nice find Deozaan, that gets a little closer to my interests.

Gothi[c]

  • DC Server Admin
  • Charter Honorary Member
  • Joined in 2006
  • ***
  • Posts: 873
    • View Profile
    • linkerror
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #8 on: May 16, 2008, 08:17 PM »
Forking is just a result from a natural desire of developers to implement their own wishes into a project if the main branch is unwilling to do so. If you license your project under the GNU GPL, any forks will have to be released under the same license. Therefore you can freely backport any useful development back into your program. I see forks only as a positive thing, broadening the software choices.

steeladept

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,061
    • View Profile
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #9 on: May 17, 2008, 02:59 AM »
 I agree with Gothic.  While you may not get credit for the base project if someone swoops in with marketing gimicks, the license (GPL, this may not apply for others) prevents them from preventing you to incorporate their work back in.  Merging, if you will.  There is nothing that stops it and it can only allow for better flow of ideas and talent.  I equate it (somewhat) to plug-ins for other software.  The obvious difference, of course, is the ability to bundle it and force it down the user's throat; er, I mean, make them install that critically needed feature whether they know it is critical or not.  ;)

Seriously, though, I don't see forking a problem, and if you really want to prevent it but maintain the open license for moral reasons, then be sure to build a rich and robust plugin architecture.  Kinda like a little program I know of that does a great job of this.  You may have heard of it <cough> FARR </cough>.

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #10 on: May 17, 2008, 04:59 AM »
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.
- carpe noctem

Lashiec

  • Member
  • Joined in 2006
  • **
  • Posts: 2,374
    • View Profile
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #11 on: May 17, 2008, 11:07 AM »
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?

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.

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

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #12 on: May 17, 2008, 11:15 AM »
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.)
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.
- carpe noctem

Lashiec

  • Member
  • Joined in 2006
  • **
  • Posts: 2,374
    • View Profile
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #13 on: May 17, 2008, 11:22 AM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #14 on: May 17, 2008, 03:03 PM »
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..

Lashiec

  • Member
  • Joined in 2006
  • **
  • Posts: 2,374
    • View Profile
    • Donate to Member
Re: Forking in Open Source Projects - Debate
« Reply #15 on: May 18, 2008, 01:14 PM »
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..

I don't think such license exist for what you mention. In the case you're considering there would no other solution that to find a middle ground, both parts should lose and gain some freedoms to partly achieve their goals. In other words, you should opt for a custom license that let other parties fork your project under a specific number of reasons, or after a discussion between the maintainers of the original project, and those wishing to fork it.

In other news, the newly release Pidgin 2.4.2 implement some of the changes that prompted the creation of Funpidgin.