Boost logo

Boost :

Subject: Re: [boost] RFC: Community maintained libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-12-07 14:59:00

On 6 Dec 2013 at 21:05, Rob Stewart wrote:

> Perhaps, but you haven't improved my understanding. So far, this seems
> like a lot of handwaving. I don't mean to suggest that you don't truly
> think the problem exists generally, but I haven't seen a pattern.

I stated some opinions of mine without any supporting facts. So yes,
hand waving. It might be useful to others or not.

> >>> 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.
> You previously used the phrase, "those interested enough fork a
> library", but when I challenge your point, you decide that forking
> requires many libraries taken elsewhere?

I'll copy and paste from

"The term often implies not merely a development branch, but a split
in the developer community, a form of schism"

Forking isn't usually about software, it's about differences in the
philosophy behind the software. For example, in the "Why POCO"

"Yet, even ACE or Boost, although top-quality well-designed code,
could not completely make me happy and convince me to fully commit.
Somehow, something did not feel right. Enter Poco. It was one of
those things you find and immediately know that´s it - you´ll be able
to really use it, and use it with joy and enthusiasm. It was C++. It
was well thought-out, well designed and really neat and tidy."

So while POCO and Boost don't share code and therefore are not forks
of /software/, they do share similar goals and purposes as general
purpose platform abstraction libraries and POCO's authors thought
that they could do better than ACE or Boost for their particular
problem set. In POCO's case, they explicitly felt that POCO would be
well thought out, well designed and really neat and tidy, and usable
with joy and enthusiasm which implies that ACE and Boost as a whole
is not those things in their opinion.

Does this improve your understanding?


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at