Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-03-19 23:13:27

On 3/19/2010 4:14 AM, Vladimir Prus wrote:
>
> Hello,
>
> in a recent post, Dave listed a few things that he thinks are wrong
> with Boost development, at present, quoting:
>
> 	I know I'm not the first person to notice that, as Boost has grown, it
> 	has become harder and harder to manage, Subversion is getting slow,
> 	our issue tracker is full to overflowing, and the release process is a
> 	full-time job.
>
> It seems to be important, right now, to discuss whether this problems are real,
> and what problems are most important. So, I would like to ask that everybody
> who is somehow involved in *development* -- whether in writing code, triaging bugs,
> sending patches, or managing thing, list three most important problems with Boost now.
> Please keep the items to a sentence or two, so that we can easily collect the
> problems.
>
> Here's my take:
>
>      - Unmaintained components. Many authors are no longer active, and we have
>        no procedures for taking over.
>      - Reviews that are getting rare and, IMO, less interesting then before.
>      - Turnaround time of test results

I think it is also important to ask boost end-users what are the 
perceived problems with Boost.

If I may answer that, as an end-user, I first want to say that from the 
end-users perspective the problems with Boost are highly overrated. It 
is still the premier set of libraries for native C++ development.

The main problem from an end-user's perspective is the first one you 
mentioned above. There are Boost libraries which have a few bugs but 
which simply do not get maintained and it is simply because the library 
developer, for very human reasons, does not want to continue to maintain 
the library. I do not know the solution to this but I strongly suspect 
that when the developer of a library does not want the responsibility to 
maintain it anymore that it needs to get passed to someone else who is 
willing to maintain it, or else marked in Boost
as not being maintained and thertefore deprecated. I know the latter 
sounds harsh but the truth is that if no developer wants to maintain 
software which has problems, or is possibly in need of additions or 
changes, then the software eventually become unusable. So I would say 
that anyone submitting a library to Boost needs to understand that once 
that person no longer wishes to maintain that library, the ability to 
maintain it reverts to Boost and the original developer can no longer 
claim that library as his own. To me this seems to be realistic. I view 
it as very human for a developer to not want to maintain software in 
perpetuity so I see nothin wrong with this suggestion.