Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review

Subject: Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review
From: Tom Brinkman (reportbase_at_[hidden])
Date: 2009-11-19 19:32:15

Vladimir Batov wrote

>> Yes, it sounds very uplifting and inspiring... and I would agree with that
>> whole-heartedly... if I considered Boost merely the place of purely academic
>> exercise. For many "average" programmers though the Boost libs is first and
>> foremost a product that they want to *use* uniformly throughout a project, many
>> projects. In that light from the commercial deployment and project management
>> points of view having 2 (or worse -- plethora of) functionally-similar
>> facilities readily available is a nightmare as some will end up using one
>> facility and some others will prefer another facility. Shared knowledge is
>> fragmented (people rarely have time and capacity to know all), code reviews,
>> maintenance are difficult, the ultimate product looks unprofessional due to
>> inconsistencies (in case of logging configurations, formats, destinations will
>> be different). It's not an imaginary situation -- our project for various
>> reasons ended up using 3 logging facilities with the very real problems
>> described above. Rectifying the problem now is an expensive and tiring exercise.

>> Do not get me wrong. I am all for creativity, innovation and healthy competition
>> of ideas. However, all that does not have to be dumped onto the user to decide
>> -- users often have no time, capacity, qualifications, freedom to make an
>> educated choice. More so, users often *want* the gurus (and the level of the
>> Boost community is most certainly considerably higher than the average) to make
>> that educated choice for them. It's like one going to a financial planner for
>> help and the planner dumping all the options on to that poor soul. Now that poor
>> customer/user has to be a financial planner himself to make an educated choice.

It seems to me that you are trying to make boost into something its not.

Boost has never been in the business of picking the best
library in a particular domain.  Its a place where promising
libraries can live for a while, get used, and inspire new ideas and
approaches.  Some of these might make into the c++ standard.

I do however agree with your larger point that boost does not SCALE well.

Ten years from now, its highly likely that boost will become too large
to manage.

People will eventually start asking to distribute boost in parts, where
the "core" libraries are separated from the "experimental" libraries.

For boost to remain popular and successful, this issue will eventually
have to be addressed.  Fortunately, it probably does not need to be
addressed for a few years.