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: Jim Bell (Jim_at_[hidden])
Date: 2010-12-18 11:26:41

Thanks for your thoughtful reply.

On 1:59 PM, Dean Michael Berris wrote:
> WARNING: This is a long post. The tl;dr version is: 1) follow the
> Linux Kernel development model 2) Employ the web of trust system using
> GPG keys 3) we need a Boost Foundation like the Linux Foundation 4) we
> need to lower the barrier to entry for would-be contributors 5) use
> Git/Mercurial for distributed development.
>
> On Fri, Dec 17, 2010 at 11:23 PM, Jim Bell <Jim_at_[hidden]> wrote:
>> [...]
>> The crux of Boost.Guild's debate. And so many topics touch on this.
>>
>> So how would you measure, or design a test, to determine how badly
>> things would get screwed up under various scenarios?
>>
> [snip excellent but time-consuming ideas...]
> A Boost foundation that has stakeholders funding it to ensure that
> Boost keeps going as a project and compensate those people who would
> do this full-time but otherwise can't because of their employment (or
> lack thereof) would be a Good Thing (TM) IMHO.

Compensating people would definitely bring a solution. So is the
solution to pursue that aggressively? How many FTE's are on staff with
Linux? How many would we ask?

Does the Linux kernel have metrics? How long does an average change sit
in the queue?

>>> Thinking out loud here... one option might be for someone to say "I'm
>>> going to try and give library X a decent update" and solicit the
>>> mailing list for bug/feature requests, then carry out the work in the
>>> sandbox and ask for a mini-review - at which point you're sort of
>>> lumbered with being the new maintainer ;-)
>> If someone is that motivated. But could something useful happen if ten
>> people, each 1/10th as motivated, were to apply themselves?
>>
> I think the having to say it to the mailing list part and asking for
> permission is the wrong way of going about it. I think, if someone
> wants to do it, they should be able to do it -- and if their code is
> good and the community (or the people that the community trusts) vote
> with their pulls, then it gets folded in appropriately. For the matter
> of having 10 people work on it, I don't think it will change the
> situation.

I'm much less concerned about a library's future direction than I am
it's present quality.

> If we use the current system of the maintainers being the BDFL's for
> the projects they "maintain" and not allowing anybody else to take the
> library in a different direction and letting the community have a
> choice on the matter, is I think, not scalable. I would much rather
> have 10 implementations of a Bloom filter, let the people choose which
> one is better, and then have that implementation pulled into the main
> release. The same goes for all the libraries already in the
> repository.

Ten implementations makes everyone spend time deciding on which to
adopt, and multiplies the MIA maintainer problem. (Will my choice's
maintainer go MIA? How do I know?) A peer-reviewed best helps me more as
a user.