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: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-19 04:59:20

On Sun, Dec 19, 2010 at 4:39 PM, Dave Abrahams <dave_at_[hidden]> wrote:
> 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.
>

Yep. And there would basically have to be either one, or a set of
people who act as the BDFLs.

In the end the hierarchy allows the structure to scale in a non-linear
fashion without significantly bogging down the whole process.

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

Off the top of my head, commercial interest would mostly come from the
bigger users of Boost -- last I checked those would be the likes of
Adobe, Facebook (?), maybe Google (?). Also the Linux Foundation is
structured in a way that allows anybody -- big and small -- to sponsor
the development of a particular part of the library or particular
fellows.

Thinking about it a little more, even those commercial interests
outside of the US might be willing to contribute. Just getting
feedback from the people using Boost would be a good thing to do if
anybody else is willing to pursue this direction.

HTH :)

-- 
Dean Michael Berris
about.me/deanberris