Subject: Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
From: Bruce Adams (tortoise_74_at_[hidden])
Date: 2010-12-16 06:04:41
----- Original Message ----
> From: Mateusz Loskot <mateusz_at_[hidden]>
> To: boost_at_[hidden]
> Sent: Thu, December 16, 2010 10:17:34 AM
> Subject: Re: [boost] [OT] Open Source Forking and Boost (was Re:
>[SQL-Connectivity] Is Boost interested in CppDB?)
> On 16/12/10 03:26, Dean Michael Berris wrote:
> > On Thu, Dec 16, 2010 at 11:17 AM, Marshall Clow<mclow.lists_at_[hidden]>
> >> On Dec 15, 2010, at 6:48 PM, Dean Michael Berris wrote:
> >>> I agree with you, but getting the current maintainers -- who are
> >>> technically, not maintaining the libraries -- to yield maintenance at
> >>> least to the whole community (or to a larger set of contributors)
> >>> hasn't been "proven" yet at least for Boost. I know Boost.Thread had
> >>> been taken over successfully before, that precedent required having to
> >>> track down the (sole) original maintainer, getting him to agree and
> >>> yield to a specific person, sounds like a lot of work compared to just
> >>> people clicking a button to "fork". :D
> >> I didn't have any trouble "taking over" Boost.Array.
> >> I asked around, no one had any problems with it, and it was done.
> > Sure, but you did have to get the OK from the original maintainer right?
> Is it a requirement to receive a Go from an original author?
> I thought there is a mechanism in Boost that grants the Community
> permission to make decisions if an author/maintainer disappears without
> any contact.
> Best regards,
> Mateusz Loskot, http://mateusz.loskot.net
> Charter Member of OSGeo, http://osgeo.org
> Member of ACCU, http://accu.org
I really shouldn't get involved in this but...
You need to move away from the idea of code ownership, especially
in the context of a community project.
In a way it is a nonsense to require permission of the maintainer.
The maintainer is more like a moderator that an owner.
In a professional context if someone does not have time to work on
a piece of code or leaves the company then whoever needs to make
a change to it makes it. Its better to be more agile still and say its always
the person who needs to make the change that makes it.
The maintainers role is review and accept or reject patches.
If the maintainer disappears then the responsibility for review falls to the
looking out for and or using that package.
With something like boost with strong review processes that should be relatively
For other projects, if the source code repository is inaccessible or your change
rejected but you believe strongly it should be included and cannot persaude
even after review then you can fork but you'll have to take the hit of doing all
maintenance work yourself if you want anyone else but yourself or your team to
use your project.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk