Re: [boost] RFC: Community maintained libraries

Subject: Re: [boost] RFC: Community maintained libraries
From: Nevin Liber (nevin_at_[hidden])
Date: 2013-12-06 17:29:24

On 6 December 2013 12:17, Niall Douglas <s_sourceforge_at_[hidden]> wrote:

> On 6 Dec 2013 at 5:26, Rob Stewart wrote:
> > Signals2 is an excellent example of just such a thing. We also have
> > cases like Lambda vs. Phoenix.
>
>  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).

This sounds like a non-problem to me.  I understand why people fork
languages or a particular library, but a complete set of libraries?  The
only fork I can possibly imagine is, say, making a C++11 or C++1y specific
version as a baseline.

We would
> almost certainly unite to see off the challenger, and that's a huge
> barrier to entry.
>

Would we?  I can't imagine something like that being successful unless the
Boost development community was so divided that a significant fraction move
over to the forked project while the others stick with Boost, and that
community division would be the problem we need to deal with.

> 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).

*shrug*  Unless you are mentioning actual examples, it is still just
abstract and only in your opinion.

What exactly is a Boost competitor?  Someone else who wants to contribute
libraries to the C++ community or the C++ standard?  Good for them!

> Some have had a reasonable success, but
> none to my knowledge has ever really come close to displacing Boost.
>

Seriously?  Who out there wants to put Boost out of business?  Without
specifics, this is just FUD.

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

No one can say what the future holds.  More FUD.

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

What does "not long far out" mean?  A year?  Ten years?  Before C++
collapses under its own weight (another oft-said prediction)?  Heat death
of the sun?  Again, without specifics, this is just FUD and a non-problem.

IMHO, of course,
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]