[boost] The future and present of Boost

Subject: [boost] The future and present of Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-21 15:51:00

This was on another thread. Someone mentioned that it should be on it's 
own thread so here it is (slightly amended for context).

For some time I've been concerned about the future of Boost as an 
organization.  Here are the concerns I have:

a) With C++11, the standards committee accepted a large portion of Boost 
into the standard.  This left it unclear as to what the future value of 
Boost to C++ might be.

b) The standards committee has ramped up it's efforts to include library 
proposals directly into the standard - thus side stepping the 
traditional requirement of "standardizing established practice".  So 
this has left Boost, which helps to evolve "establish practice" outside 
of the development of the C++.  An example of this has been the Ranges 
library which as been designed and developed totally within confines of 
the C++ standards committee.  This effectively marginalizes Boost - that 
is, makes it less relevant and important.

c) This effort by the committee is basically failing.  It's creating the 
possibility that C++ will evolve into an ever larger and 
incomprehensible bag of disjoint features than it already is. It makes 
it much harder to learn C++. This puts C++ on a slow train to oblivion. 
This is not unusual with successful projects which expand their scope - 
as the committee has done.  It's especially common for organizations run 
as a committee.  Think large corporations: Kodak, Sears, All government 
organizations, universities - etc.

All one has to do to see this is look at the papers list for the San 
Diego meeting.  Also look at P0977r0.  Consider that it take the 
committee 10 years for a proposal to evolve into something that can be 
delivered to users. It even takes 10 years to include something which is 
already in use by 100's of thousands of programmers - ASIO.

Of course the C++ committee won't address the situation.  Committees 
don't do that. They think they can remain relevant by expanding scope. 
and lo and behold, now they want to expand scope again to include 
tooling.  Wake up and smell the coffee people.  Learn to prioritize and 
limit the scope of your actions to that which only you can do.  This 
would be better for C++.  Do less - get more done!

d) Boost can accept, review and deliver a new library in a year. Hence 
Boost has a reason to continue and exist. But Boost is also a committee 
- albeit a better designed one. It has to evolve as well. I think it can 
evolve if we continue to work on the stuff we've been successful at 
while at the same time experimenting with new ideas.

Robert Ramey