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: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-15 08:42:53

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.

> X.org is a fork and successful indeed.
> MariaDB was as necessary answer to MySQL closed for community-driven
> development.

And is a fork -- everybody could have continued with contributing to
MySQL and assigning rights to Sun (now Oracle), and most of the
(public) innovation is happening on the MariaDB side.

> Though, I haven't seen a lot of critical mass around MariaDB.
>

Yet. ;)

>
> Dean Michael Berris wrote:
>>
>>
>> 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.

> In many cases it meets same problems as any other startup project.
>

Sure, but the maintenance problem that was there is solved by the new
project because the new one is maintained at the time of the fork.

>
> 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.
>

So, what else is there aside from code/documentation in an open source
software project?

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.

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

Funding -- well, it's the same issue that any other open source
project faces anyway, I don't see why a fork would be especially
harder to fund than any other project.

With forks, you'd have that "scratch your own itch" and "build it and
they will come" mantra's. Unless you do both, you're not going to get
far, and this applies to any open source software project.

>> 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.
>

See, the other part you missed is the question "who's with me?".
Anybody can fork any open source project, that's a given -- but then
getting critical mass behind you to be successful is something else.
Now, let's say you are charismatic and can get people behind you to
leave the original project behind and take the fork to a different
direction, then I don't know what the problem with forking is -- aside
from, well, potentially killing the original project, which sometimes,
is a good thing.

>
> 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.
>

Hehe, to each his own then. ;)

> 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".

> 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. ;)

> Best regards,

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.

This might just be me though. ;)

-- 
Dean Michael Berris
deanberris.com