On Sun, Dec 19, 2010 at 4:39 PM, Dave Abrahams <dave@boostpro.com> 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