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