Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)

Subject: Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
From: mloskot (mateusz_at_[hidden])
Date: 2010-12-15 07:54:33

Dean Michael Berris wrote:
> 
> On Wed, Dec 15, 2010 at 7:45 PM, Mateusz Loskot <mateusz_at_[hidden]>
> wrote:
>> On 15/12/10 02:20, Dean Michael Berris wrote:
>>>
>>> On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot<mateusz_at_[hidden]>
>>> wrote:
>>>>
>>>> This is not how FOSS works to make a project healthy and
>>>> sustainale in long term. Your observable disappointment about
>>>> software here makes me asking, what's next? Boost libraries
>>>> forked?
>>>
>>> Well... actually... forks are a valid means of diversification in
>>> FOSS projects.
>>
>> Technically and formally valid, but not necessarily valid in terms of
>> sustainability. Thinking in terms of r/K selection theory, which one
>> would be better for FOSS (assuming no funds).
>>
> 
> Here's the thing though, if the fork succeeds, it eventually becomes
> the "main" project. This has already happened with MariaDB and MySQL,
> Firefox and Mozilla, X11 and X.org, etc.
> 

Firefox is not a fork, but the same team and the same organization decided
to change their strategy
from the Mozilla Suite to two separate products.
X.org is a fork and successful indeed.
MariaDB was as necessary answer to MySQL closed for community-driven
development.
Though, I haven't seen a lot of critical mass around MariaDB.

Dean Michael Berris wrote:
> 
>>> About Boost Libraries being forked, I don't think that's inherently a
>>> bad idea -- especially since there's already a number of Boost
>>> libraries that seem "unmaintained".
>>
>> Forking never solves maintenance problems, but introduces new ones.
>>
> 
> Not really.
> The fact that something is unmaintained and that people other than the
> original maintainers want to maintain a fork of it, I don't see how it
> introduces a new maintenance problem. 
> 

There are plenty of new problems.
Forking is not about copying, changing and throwing out on the public
server.
In many cases it meets same problems as any other startup project.

Dean Michael Berris wrote:
> 
>>> The only issue I see with forking Boost libraries at this time is the
>>> infrastructure used to host the code; SVN wasn't meant to encourage
>>> forking compared to say how Git or Mercurial allow forking to be as
>>> trivial as branching and merging. I'll leave my comment on SVN at
>>> that at risk of inciting the SCM debate yet again. ;)
>>
>> Forking projects is not the same as forking in Git (like at github).
> 
> Eh?
> 

Yes, it's not just copying a code, as long as we both understand a project
is not
only a source code. Code is an extremely important part of a project, but
it's
not critical part. As every piece of software is useless without data,
any forked source code is dead without community which uses and maintains
it.

> Forking a project is similar to this story:
> Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks.
> let's leave it and make new Rome v2 in south-west.
>

Dean Michael Berris wrote:
> 
> That's a re-write, not a fork. A fork would be:
> 
> Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks;
> who's with me, I'm going to bring the good parts of Rome and build a
> city that's in the south-west but this time with dedicated cleaners,
> hospitals, proper waste management facilities, and cool new sights.
> 

I've assumed the "bringin the good parts". I should have made it clear.

Dean Michael Berris wrote:
> 
>> I joined this thread because I could not understand the sociological
>> aspect of this decision. Perhaps it's me and nowadays more folks
>> consider it easier to quit a job than to work out a compromise :-)
>> I honestly wish Artyom good luck.
> 
> Well, these days I think at least compromises seem to be overrated. If
> you can't get to Win/Win, there's always No Deal. ;)
> 

I don't think compromises are overrated.

My general point is that it's easy to fork (as it's easy to create new FOSS
project),
but following steps are very difficult to make it success.
What I have observed here, is what I'd call "premature forking" and that's
why I don't 
understand such decisions.

Here is article that precisely explains my concerns, especially:

When to fork?
When you have exhausted all other options.

http://fossfaq.com/questions/52/what-does-it-mean-to-fork-an-open-source-project

I have not seen such exhaustion.

Best regards,

-----
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
-- 
View this message in context: http://boost.2283326.n4.nabble.com/OT-Open-Source-Forking-and-Boost-was-Re-SQL-Connectivity-Is-Boost-interested-in-CppDB-tp3088354p3088940.html
Sent from the Boost - Dev mailing list archive at Nabble.com.