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/