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@jc-bell.com> 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.