Open Stack

On Fri, Jun 12, 2015 at 08:33:56AM -0700, James Bottomley wrote:
> On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > > What about code history and respect of commit ownership?
> > > I'm personally wondering if it's fair to copy/paste several thousands of
> > > lines of code from another Open-Source project without asking to the
> > > community or notifying the authors before. I know it's Open-Source and
> > > Apache 2.0 but well... :-)
> > 
> > Being able to copy code without having to ask for permission is exactly
> > what Free Software (and more recently, Open Source) is for.
> 
> Copy and Paste forking of code into compatibly licenced code (without
> asking permission) is legally fine as long as you observe the licence,
> but it comes with a huge technical penalty:
> 
>      1. Copy and Paste forks can't share patches: a patch for one has to
>         be manually applied to the other.  The amount of manual
>         intervention required grows as the forks move out of sync.
>      2. Usually one fork gets more attention than the other, so the
>         patch problem of point 1 eventually causes the less attended
>         fork to become unmaintainable (or if not patched, eventually
>         unusable).
>      3. In the odd chance both forks receive equal attention, you're
>         still expending way over 2x the effort you would have on a
>         single code base.
> 
> There's no rule of thumb for this: we all paste snippets (pieces of code
> of up to around 10 lines or so).  Sometimes these snippets contain
> errors and suddenly hundreds of places need fixing.   The way around
> this problem is to share code, either by inclusion, modularity or
> linking.  The reason we paste snippets is because sharing for them is
> enormous effort.  However, as the size of the paste grows, so does the
> fork penalty and it becomes advantageous to avoid it and the effort of
> sharing the code looks a lot less problematic.
> 
> Even in the case where the fork is simply "patch the original for bug
> fixes and some new functionality", the fork penalty rules apply.
> 
> The data that supports all of this came from Red Hat and SUSE.  The end
> of the 2.4 kernel release cycle for them was a disaster with patch sets
> larger than the actual kernel itself.  Sorting through the resulting
> rubble is where the "upstream first" policy actually came from.

Thanks for the excellent summary of the technical penalties incurred by
straying too far from upstream.

It's funny how after years of trying to convince Fuel developers to put
more effort into collaboration with upstream, in this thread I managed
to come across as if I were arguing the opposite. To reiterate, I
understand and support the practical reasons to reduce the gap between
Fuel and Puppet OpenStack, and I believe that practical reasons are a
much better way to motivate Fuel developers to collaborate than arguing
whether what Fuel team has done in the past was fair or wrong.

-- 
Dmitry Borodaenko