Boost logo

Boost :

Subject: Re: [boost] Unmaintained libraries (Was: 5 Observations - My experience with the boost libraries)
From: Jim Bosch (talljimbo_at_[hidden])
Date: 2010-03-24 18:48:24

On Thu, 2010-03-25 at 01:02 +0300, Vladimir Prus wrote:
> Edward Diener wrote:
> > he license is one thing and even the "Library Maintainer's Rights and
> > Responsibilities" which Steve Watanabe links to in another post is
> > another, but unless someone with authority decides that library X, being
> > ignored by the maintainer, needs to be taken over by another who is
> > amenable to fixes and changes, it is not going to happen. The main
> > reason is somewhat psychological. If an end-user complains that
> > maintainer X is not responding to requests about library X it will be
> > seen as a derogatory put down of maintainer X. If a boost developer
> > complains it may also be seen as a form of competitive envy. Despite
> > your objection to Boost "leaders" someone has to take the bit between
> > the teeth in order to effect change.
> I think you propose not the best way to approach the problem of abandoned libraries.
> Suppose there's a formal procedure of taking over. Like, an email is posted saying:
> Library X is unmaintained. If you would like to take maintenance over,
> and fix the 50 bugs currently filed against it, and also fix all new
> bugs, step forward.
> Do you expect many people will volunteer? On the other hand, if fixing a bug in
> library X does *not* require any formal process and takes 5 minutes, it's much
> more likely that bugs will be fixed. I think we need to have an official
> "it's ok to apply patches everywhere" policy more than anything else.

I think distributed, decentralized bug-fixing is exactly the right model
- for bug fixing - and I think that's all most stable boost libraries
need. And honestly, even the libraries which don't seem to be getting
much attention don't seem to have much in the way of serious bugs.

There are a few that could do with more active, intrusive development,
however (even if it's just to make the library more interoperable with
newer boost libraries), and I think that might require a small group of
people who are actually in charge of where that library goes in the

Maybe all that's needed is a review process for proposed major updates
to a library. Perhaps it would be better to have a commitment to
re-reviewing existing libraries every N years, so the whole community
can get involved, review-style, on where a library should go next.

Jim Bosch

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