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: Dave Abrahams (dave_at_[hidden])
Date: 2010-12-19 03:39:07

At Sat, 18 Dec 2010 14:00:09 +0800, 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.
> 
> Now, that doesn't remove the maintainer dilemma -- but the beauty of
> that system is, even when a maintainer of a subsystem suddenly goes
> MIA, the community can decide to just pull from a different person's
> repository. Then, being a maintainer of a subsystem becomes no
> longer a choice of the original maintainers, but mostly the
> contributors. Let me try and explain a little bit more.
> 
> If I'm a developer A, and there's a maintainer B who's supposed to
> be handling the module X, all I do is clone B's repository locally,
> make my changes, and then ask maintainer B to pull my changes. I can
> send him the changes via email, I can post the changes publicly (and
> sign it with my GPG key), or I can expose my repository publicly so
> that anybody (not just B) can get it. That should be simple enough
> to understand.
> 
> What happens when B goes MIA or unresponsive? That's simple, I ask
> someone else -- maybe Linus, or maybe some other higher-level
> maintainer, or just someone the community already trusts -- to pull
> my changes in. Losing maintainer B is not a hindrance anymore
> because the community can start pulling from each other and stamping
> their trust and confidence on the code. Later on the community just
> elects by way of pull requests who it trusts to be a maintainer of a
> subsystem.
> 
> This sounds like some pie-in-the-sky dream, but this is the reality
> already with the Linux kernel development. It is the single project
> I know that spans the globe with thousands of contributors. This
> model is already proven to scale.

One problem I see coming is that we have a very simple two-level
hierarchy: there are library maintainers and release managers.
There's nobody at an intermediate level who's responsible for a large
group of libraries that would correspond to a Linux "subsystem."  Not
insurmountable, but we'd need to invent a structure for it.

> 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.

Interesting thought.  What stakeholders do you think would be willing
to provide funding?

> >> 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.

+1

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com