Subject: Re: [boost] RFC: Community maintained libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-12-06 13:17:23
On 6 Dec 2013 at 5:26, Rob Stewart wrote:
> >> I've not explained myself well enough. What I'm proposing should not make community reps feel they have to contribute to multiple libraries.
> >> Just that they shouldn't be _prevented_ from contributing to libraries, whether that be the one library they have an intereste in, or more than one.
> Perhaps the issue is that those relatively new to Boost don't understand
> what happens, over the years, that seems normal to longtime members of
> the community. Documentation would solve that.
Personally speaking I've been here since 2002 or so, but you didn't
see me on this specific list till recently. I was busy with other,
non compsci related efforts.
I think the OP was referring to lack of universal commit access for
the git config, not the preceding SVN config.
> > Even if everyone had commit access to everything, I think you'd find
> there are powerful social pressures to not fiddle with "other people's
> code" except in the most minor ways.
> That's always the case and it serves to squelch overreaching change.
Except that isn't the case in other open source, as the OP also
pointed out. Boost is an outlier on the primacy it places on
individual maintainers and their control of "their" code. Don't get
me wrong, it has huge benefits, but it also comes with penalties,
mainly the lack of a holistic design and vision across all of Boost
and what happens when a maintainer becomes unavailable.
> > Even substantial patches are highly likely to be silently ignored by most maintainers,
> > partially due to NIH, partially due to lack of interest in merging
> > and supporting other people's use cases, and partially because in the end it's all about spare time here, and people will naturally choose their todo list over other's.
> The superlative, "highly," mischaracterizes the attitude of most Boost maintainers.
I think you also mischaracterise my use of "substantial".
> > The traditional solution is forking of course, so those interested
> > enough fork a library and take it in new directions. Boost is
> > particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost.
> Signals2 is an excellent example of just such a thing. We also have
> cases like Lambda vs. Phoenix.
That's evolution of a component, not forking which would involve
multiple libraries being taken in a new direction together. Forking
is where a challenging group substantially disagrees with the
controlling group enough to expend significant resources to prove
themselves correct. Forking only succeeds when the challenging group
acquires enough resources and is more correct than wrong in their
basis for forking. For a challenging fork to supplant the original,
it also requires the controlling group to lose legitimacy.
Boost code is hard to fork mainly because it's particularly hard to
write and maintain, but more importantly a direct challenge to the
purpose and goals of Boost by a forking group would be seen as a
personal attack by most here (including me, by the way). We would
almost certainly unite to see off the challenger, and that's a huge
barrier to entry.
This all may seem quite abstract, but there have been more than one
Boost competitors over the years which sought to "do Boost better"
whether implicitly or explicitly (with some alternatives coming from
multinational corporations). Some have had a reasonable success, but
none to my knowledge has ever really come close to displacing Boost.
In that sense what has worked has worked very well - till now. We
can't easily say yet if the present maintainer-led system will scale
out. I personally think - and I'll put on my hat as a Complex Systems
researcher now - that the tipping point where it stops working well
is not long far out, especially now modularisation has been
implemented which will speed up the complexification of the Boost
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk