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: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-12-15 09:14:08

On 15/12/10 13:42, Dean Michael Berris wrote:
> On Wed, Dec 15, 2010 at 8:54 PM, mloskot<mateusz_at_[hidden]>  wrote:
>> Dean Michael Berris wrote:
>>>
>>> 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.
>
> Which is by definition, a fork.

Technically, yes but organizationally no.
The same organization, the same people.

I'll remind, I'm considering a project as the whole machine producing
a code. A project is not only a code.

>>> 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.
>
> Eh? That's the simplest definition of a fork. Unless I'm missing what
> you mean by fork.

I've tried to explain it at least two times.

>>>>> 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.
>>
>
> So, what else is there aside from code/documentation in an open source
> software project?

http://producingoss.com/

> Community of users and developers -- well, if it's a fork, you can
> build that community on your own or potentially get people from the
> original project.

You can or you can not.
There are plenty of reasons why users and developers won't drift
with forks.

> Support fora -- well, you can (easily) create mailing lists now and
> even online web forums to provide community support.

Technically, it's easy. Next, you have to have time to maintain the 
traffic, answer questions, provide support. When you have 100 folks
subscribed, it's easy to spend 2 hours a day on it.

>> 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.
>>
>
> Okay, but making something successful involves work -- regardless of
> whether it's the fork or the original project. So I don't see why
> forking should be discouraged even if there is no good reason to do it
> aside from "well, because I can and I want to".

You still don't understand my point.
I'm not trying to discourage forking. I'm not suggesting forks are evil.
I'm commenting very specific situation which has emerged and
the reasons which are unclear to me.

>> 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.
>
> I actually disagree with that answer.
>
> You fork when:
>
> - You want to.
>
> It should be that simple really. ;)

We all are free as wild pigs and we can do whatever we wish.
I'm trying to stay with frames of reasonable thinking
and strategic planning, with some principles of business.

If there is no pragmatism and rationale behind your decision
but "want to" then it's ego-driven development.

> HTH
>
> By the way, my assertion is that forking, in general, isn't a bad
> thing; that diversification should be encouraged especially if it will
> bring innovation and covering new ground. The consolidation can happen
> later on when the good ideas can start cross-pollinating across the
> diverse tracks, and improve the overall state of the art.
>
> I am by no means willing or even remotely considering forking Boost
> libraries -- especially since I cannot maintain any new Boost
> libraries other than the one I intend to submit for review and develop
> on my own. However I don't see why anybody who has the wherewithal or
> the motivation to actually either take over some of the Boost
> libraries in a fork -- heck, or the whole Boost project for that
> matter -- should be discouraged from doing so.

I agree with this, actually, but it's slightly far from the point
of this specific situation I've tried to ask about and understand.

If someone says "I don't want to do it, to maintain new piece of
software myself, but I have no choice" but there is no track of
discussion that would lead to such conclusions, then I'm far from
understanding such what's the real reason.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org