Re: [boost] RFC: Community maintained libraries

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 
ecosystem substantially.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/