Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
From: Ahmed Charles (acharles_at_[hidden])
Date: 2013-10-31 05:08:50
> Date: Thu, 31 Oct 2013 00:14:27 -0700
> From: mcaisse-lists_at_[hidden]
> To: boost_at_[hidden]
> Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
> On 10/30/2013 07:28 PM, Ahmed Charles wrote:
> > I know you mean well, but I believe the problem is that anyone who has the political capital required to change the process isn't invested in changing it and everyone who is invested in changing it doesn't have the required political capital to change the process.
> Ahmed, I appreciate your comments and the time your took to articulate
> them. Considering the care you have demonstrated in your initial post as
> well as your responses, I suspect your thoughts have added "value" already.
> In May 2011, a group was formed called the Steering Committee. While I
> was not involved in the detailed discussions that led to the formation,
> I do recall the ML activity and BoostCon sessions preceding the
> announcement. Consensus was the rule prior to the formation of the
> Steering Committee. I have tremendous respect for those who brought
> about Boost and their humility shown within the operation of the
> organization. Their realization that consensus had become unattainable
> and the organization was stagnating drove the formation of a group of
> peers to help guide Boost. While it might seem as if Boost is aimlessly
> wandering or lacks direction save the incidental movement caused by the
> summation of each author's will, there is a group that can intervene and
> provide uniform purpose.
I work in the same office as a member of the steering committee (you knew that though :) ) and I've talked to him (Jon Kalb) about this on a few occasions. My impression of the steering committee is that while it was formed to serve lots of purposes, it currently mainly serves in support of C++Now/BoostCon and hasn't really had much impact on the combined technical/political issues that face boost libraries. If there are examples (hopefully more than one) which contradict this, I would like to know. This isn't to disparage the steering committee, of course, but I know it is the intended solution and I'm trying to get things to go in that direction more and more, since it seems there isn't enough being done.
> Unlike other organizations, Boost fully respects the will of an author
> in maintaining their library. I would be dishonest if I didn't
> acknowledge that this policy has resulted in some personal head
> scratching with a few libraries over the years. In the end though, I
> believe that library authors best understand the constraints and intent
> of their libraries and how to maintain them.
I'm personally on the fence about this policy. I see some library authors that are responsive and reasonable with their library and I wouldn't want to disenfranchise them one bit. But I also see that it can create an 'old guard' sort of situation that benefits no one. With power should come responsibility and there should be a mechanism that ensures that libraries that stagnate are given new maintainers. I understand that there is a shortage of people signing up to maintain libraries, but I think at least part of that is due to the impression that libraries are only ever 'pried from the hands of their dead maintainers'.
> Sometimes we must persuade an author of a good idea or to increase their
> vision of their library. We want authors that are involved and
> passionate. I am personally uncertain about the democratization that
> occurs via libraries in Git. The ease of forking a repository has the
> potential of diluting the ecosystem, creating superior libraries through
> collaboration, or resulting in a form of natural selection. It will
> largely depend on the library's maintainer.
I look forward to being able to 'fork' boost locally and be able to manage changes to various libraries, completely ignoring the possibility that those changes will ever leave my hard drive. I simply enjoy tinkering and that's enough incentive for me to want to use git to do that with boost.
It's only inevitable that people will take it further and take things in a direction that the library maintainer doesn't want and hopefully that will provide the competition and incentive required for boost to adapt. Granted, I also think that the complexity of using submodules will stem most of the diluting of the ecosystem, since it will be hard for people to manage publishing releases via simply having a tag on github that allows people to download a zip file and get a completely working boost implementation.
I did my first pull request on github earlier to fix a typo in the readme file used in the boost/admin project and it's already been integrated by Dan. All without leaving the browser. Fixing documentation or other trivial issues could become so simple that it's a no-brainer for anyone interested in contributing while noticing that issue.
> Each year a couple of people cycle out of the Steering Committee and a
> couple cycle in. Sebastian Redl and I cycled in this past May. Your
> comments as well as those of others in this thread have me thinking. I
> can appreciate the overall frustration that many have shown in the past
> couple months on the ML. Boost is a slow moving organism. Please know
> that there are those involved who are keenly concerned about the
> "political side" and how best to create a healthy, active, and viable
> organization. I would hate to see new and energetic partners become
I agree and eagerly look forward to progress in this area. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk