I also think that in order to improve the impact of Boost, certain libraries should be retired (at least those which are now standardised). (Bigger/More is not better, Niall) Some other stuff should really go, because those libraries are really no longer of this time. I'm thinking like BGL (the manual is a book!!!), multi-array (talk about clumsy) and several others, so somebody has an opportunity and is given a challenge to create something better. Also un-maintained libs are candidates for scrapping.
You may not remember that I have one of the most aggressive opinions on deprecation of anyone here. If I had my way: * All undermaintained libraries (as defined by unclosed issues) stripped from main distro at six months, with warnings each month privately, warnings to the public from four months onwards. There are libraries in the Boost main distro with open bug count nine years old. That's unacceptable in any set of libraries claiming to have quality. Last time I looked in detail (before the corporate sponsorship effort), about half of Boost libraries had maintenance issues, but there was a hardcore 20% that is damaging the Boost brand and those need to go. * All legacy libraries removed from main distro into a "legacy" distro. I am torn on libraries like SharedPtr, those are a tough call. I'd leave it up to the maintainer to choose e.g. StringRef is clearly legacy, StringView is not. * All C++ 14 only libraries put into a Boost 2.0 distro. * All libraries in the review queue put into a "Boost unreviewed" distro. I reckon about fifty libraries would remain in the main distro. Much more manageable and focused. And by "put into a distro", I do NOT mean release management, I mean an automated script on a cronjob. No manual quality control, that is kept only for the main distro. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/