Boost logo

Boost :

Subject: Re: [boost] RFC: Community maintained libraries
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2013-12-05 15:59:58

Andrey Semashev <andrey.semashev_at_[hidden]> writes:

> On Thursday 05 December 2013 10:06:55 Steven Watanabe wrote:
>> On 12/05/2013 09:36 AM, Alexander Lamaison wrote:
>> > ========
>> > Proposal
>> > ========
>> >
>> > My proposal goes further than Beman's and gives "Community
>> > maintainership" to all but the most well-maintained libraries. Each
>> > library would still have a named maintainer and this would be their
>> > role:
>> >
>> > <snip>
>> This wouldn't help anything. Every effort to
>> create a group that does general maintenance
>> in the past has fizzled out when most of the
>> participants lose interest. If we can't even
>> manage this for a few libraries that have no
>> active maintainer at all, it's completely
>> hopeless to try to establish it for even more
>> libraries.
> While I can see why this idea may fail because of lack of interest, I
> sympathize Alexander's point that the community should play larger role in
> libraries development. There are examples when blanket changes needed to be
> applied to multiple libraries, like macro updates Stephen Kelly did. There are
> cases when trivial fixes needed to be made in someone else's library. Surely
> github adds pull requests to the available options, but pull requests still
> have to be processed by a single or a few maintainers, which become a
> bottleneck and a single authority about the library.
> I think Alexander is making a good point that the membership in the Community
> group should represent the right to apply changes and not an obligation to do
> active maintenance of every library in Boost. Such an obligation is
> unrealistic to fulfill, indeed. But for one, I'd like to be able to make
> changes to the libraries I don't develop or maintain.
> There is a slippery edge in this idea though. While I'd welcome people making
> fixes and relatively small improvements to the libraries I maintain, I'd feel
> unease if design decisions were made without my consent.

I anticipate this only happening in two rare situations, one extremely
rare. The more common case would be where a maintainer is uncontactable
or unable to devote enough time to make the changes. The second, rare
case would be where, after exhaustive debate on the list, the community
is overwhelmingly in favour of a direction for the library but the
maintainer simply refuses. It's hard to see any reason why the
maintainer should be able to veto the whole community for all time.

> It's not about the lack of trust for the community, but rather because
> such decisions could interfere with my vision of the library utility
> and future development.

Exactly. That's why the maintainer should remain in charge of the
overall direction of the library. It's just that there should be a way
to overrule them if it's clear to everyone but themselves that they are
misguided. In a small project, the community would simply fork it,
change its name, and get on with the changes. But with Boost that is
plainly impractical.


Swish - Easy SFTP for Windows Explorer (

Boost list run by bdawes at, gregod at, cpdaniel at, john at