Boost logo

Boost :

Subject: Re: [boost] The problems with Boost development
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-19 19:10:11

On 03/19/2010 11:14 AM, Vladimir Prus wrote:
> 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.

I can't call myself an active developer of Boost, but I did create quite
a few tickets, some with patches, and applied some of them. So I hope I
qualify for the survey.

First, here are my top 3:

1. The review procedure is failing to deliver new libraries to the users
in a reasonable time frame. Some very important libraries stay in the
queue for too long without even having a review manager assigned.

2. The lack of maintenance releases. In production environment it is
often a rule of thumb that the first release is unstable, and the second
(third?) security update is suitable for use. Not having such updates at
all leaves Boost in a bad situation.

3. Monolithic design limits development and adoption of Boost. A more
modular approach is needed.

I'd like to draw attention to the fact that none of these issues is of
instrumental nature. I recognize the problems with unsatisfactory
performance of Trac and complex build system of Boost, but to my mind
these are of secondary concern. A far more important thing to do is to
decide the further course of Boost development. Then the instrumental
layer will naturally follow the chosen direction.

Now, some more details on the outlined issues.

1. The review procedure.

The topic raises rather often, there are suggestions from different
participants, but it seems that nothing changes eventually. Reviews
still happen rarely, there are too few review managers, and sometimes
reviewers are also lacking. It looks like Boost has grew too big and the
core Boost community members just don't have the time to pay attention
to the new proposals. Another possible reason for this effect could be
that the interest for Boost is cooling down, but I don't want to believe
that. After all, Boost was, is and will be the place for innovative
ideas in the world of C++, and losing interest for such a place would
mean losing interest in C++ as a whole.

Anyway, I think, we should identify the reasons of this stagnation. Of
course, the first thing that comes to mind is the lack of time of the
volunteers. True, I can barely comprehend the amount of time a review
manager should dedicate to the review. This is especially true in case
of big submissions to Boost. This amount of time should be reduced. The
following ways of doing that come to mind (some were discussed earlier
on the ML, but I'll rehash):

- Introduce the voting mechanism. Voting should be as easy as clicking
on a yes/no link or icon on a web page + an optional small comment. No
ML subscription required. The review manager may take into account those
votes as an indication of public interest and appreciation of the
- Separate the mechanism of posting a full review and the library
discussion. It would make it easier to collect the formal reviews
without having to read through all the discussion. Perhaps, a separate
ML for formal reviews would suffice. A web page with a few fields to
fill in to post the review would also be very helpful, especially for
the occasional newcomers.
- Reduce the number of formal questions for the review. IMHO, three
questions of design, docs and implementation quality, plus the final
yes/no verdict should suffice for the review. The rest should be optional.
- Provide automated ways of assisting the review, such as scripts for
updating the web site for the review (e.g. post an announcement in the
news section, prepare the aforementioned web page for posting reviews,
etc.), formal mailings (review is upcoming, review has started, review
is in progress, review has finished) and whatever other things needed.

Ideally, I would like to reduce the time needed for such routine things
to a minimum.

Another reason is the lack of motivation. I think, it is fair to say
that people that invest their time and effort into Boost should be
rewarded somehow. I'm not saying that Boost should become a commercial
software (please, no!), but the appropriate acknowledgement of their
efforts should be in place (on the front page of the web site and the
release notes). Perhaps, a donation system could be established, so that
release and review managers do get monetary rewards, too. On the current
stage I don't consider reviewers to be rewarded, because the library
acceptance itself is a reward for them, as for the interested parties.
But the library author is free to acknowledge them in the library
credits page.

And the third reason I'd like to outline is the lack of people. The
problem is twofold. On one side, the entering barrier for a person into
Boost is quite high. One has to be a quite experienced developer to
participate in reviews, let alone to be a review manager. While the
review manager should be experienced, I'm not sure the requirement is
adequate with regard to the reviewers. I think it should be possible for
the less experienced users to see if documentation and examples are
clear and understandable, while the more advanced developers have more
time to evaluate the implementation and the interface of the library.

The other side of the problem is that Boost is rather closed to its
community. I don't know how it happens, but on independent news I
regularly read of such projects as KDE, GNOME, Qt, Linux Kernel and
others, but nearly nothing about Boost, which, I believe, has no less
importance in the world of C++. The Boost web site changes rarely -
essentially, the news column only lists recent Boost releases. For an
outsider, nothing really happens around Boost, and that's sad. If Boost
was more open and advertised on public (perhaps, not a good wording, but
I can't come up with a better phrase now), I think, there would be much
more activity in Boost, and during reviews in particular.

To be continued...

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