Re: [boost] RFC: Community maintained libraries

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 
http://en.wikipedia.org/wiki/Fork_(software_development):

"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" 
description:

"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?

Niall

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