Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

[Bill Nottingham]

Miloslav Trmač (mitr at volny.cz) said: 
> On Mon, Feb 27, 2012 at 4:18 PM, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> > On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:
> >> Personally, my stance on this is that, provided that the forks are
> >> properly renamed such that they will not conflict with other forks of
> >> the same codebase, there's no reason to disallow them. As mentioned by
> >> Toshio in the ticket, carrying forks provides a much better alternative
> >> to bundled libraries in the situations where the primary codebase is
> >> lacking certain features.
> >
> > There's exactly the same reason to avoid closely-related forks as there
> > is to avoid embedded libraries - if you have a security issue you now
> > have more places to fix the same bug. The question is whether that cost
> > is larger or smaller than the gain from carrying the forked code.
> 
> There is one crucial difference: A maintainer of a forked code base
> explicitly knows he is maintaining it; a maintainer of a software
> package that happens to embed a library may not think about
> maintaining the embedded library at all.

Right - we should make it clear to people packaging things like
cinnamon/muffin that it may not be the most healthy long-term alternative, and may
cause them pain in the long run. (Hey, name-based metaphors!) But as long as
they're aware of that pain, I don't see why we should deny them the
opportunity, or force them to try and port software away from the fork.

Bill