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 07:13:29
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]>
>>> Hi, I will only refer to complain on the slow SOCI release
>>> schedule. So, instead of deciding to join an existing project,
>>> which N.B. you have used with some degree of success, and help to
>>> speed its release process, help with fixing bugs and propose to
>>> add features you are missing, you decide to fork it, tweak it and
>>> release it.
>> I'm not sure but is CppDB a fork of SOCI?
> It is not a direct fork of code.
> I believe I explained it in my reply to Artyom's post.
Yep, read that too. I just wanted to check if my understanding of
"fork" was correct.
>>> 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
>> 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. -- there's no "sacredness of
the root" when it comes to FOSS, and I think that's a good thing. This
means, if the original project wasn't going according to a number of
contributor's (or community members') liking, then forking is always
The reason most forks exist is that the original approach is not
sustainable. Sustainability in the sense that original design/process
decisions were deemed wrong by some people and that they think it's
better to either do it over or gut the software/project and bring it
to a new direction than trying to fix the original. This is where the
concept of a non-sacred source makes sense -- think how CMUCL got
forked into many various CL implementations and how each one has
Also, sometimes, having just one project isn't also sustainable --
which is why forks make sense for a means of diversification and
>> 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.
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. The fork might be more actively
maintained by the people that forked the original project, or the new
project allows more contributors to get involved, or offers a better
means of iterating/innovating than the original project... in that
situation the non-maintenance project is actually solved by allowing
others to maintain it outside the original project.
>> 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).
> 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.
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 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. ;)
-- Dean Michael Berris deanberris.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk