Joaquin, et al. Agree that that there is a lot of value to be had in dividing and pruning the number of libraries in Boost. Maintained/unmaintained is not the only division that would help. There is also "currently active" vs "stable/inactive" and "consumed into the Standard in whole or major part" vs "unique to Boost". With the help of AI and digging into docs I came up with the following table - mostly focusing on the uniqueness of the library and its' activity status - it's a work in progress but the idea is to help potential new users identify current focus and directions: https://www.boost.org/doc/user-guide/library-table.html I am kind of suggesting that "Uniqueness to Boost" is the top priority for potential and current users. best - Peter On Tue, Oct 20, 2026 at 11:28 AM Arnaud Becheler via Boost < boost@lists.boost.org> wrote:
Unless a library is entirely non-functional, I don't see how removing it would help anyone.
I think different people are optimizing along different axes:
1. Maintenance allocation. Joaquin's original goal was to list unmaintained libraries so we could optimize maintenance coverage/signaling and redirect potential maintainers to candidate libraries. When maintainers are scarce, deciding which libraries to maintain is strategic, and very old libraries with a standard equivalent within Boost's baseline are natural candidates for the bottom of that list.
2. Discoverability. As an ecosystem, Boost wants newcomers to find what they need. Presenting 165 libraries, with no signal about which ones are current, to someone who is 25 years old and has always had C++11 is not a great first impression. When a user hits an unmaintained library with open bugs and no response, the cost is not limited to that library: it erodes confidence in Boost as a whole.
3. Cross repository cost. Anyone involved in cross repository work knows a library is never completely unmaintained, and the sheer number of libraries is hard to get through. Rene spent years going through every library to make Boost build modularly ( https://github.com/grafikrobot/boost-b2-modular/blob/b2-modular/README.adoc ), often having to fix obsolete CI setups, broken compilers, and so on (I helped him with 3/165 and it was already painful ahah). An obsolete library does not exist in a vacuum: it must coexist with the others, and someone pays for it, either in maintainer time or in user frustration over features that are slow to arrive (modular builds being the obvious example - several French people complained about it).
But as Rene and Vinnie mentioned, the first step is to remove internal use anyway, which should take a few years. And to begin somewhere, we should at least have some priority ranking of the libs Joaquin listed, be it for candidate maintainers matching or for planning internal use removal steps.
Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries.
Right now, the path "this lib is unmaintained" -> “i'm interested” -> “I'm maintainer” is hard (impossible?) to see from the outside. A clear handover process could help: a clickable button on the Boost website that filters unmaintained libs, who to contact, how ownership gets transferred, a trial period as co maintainer, and an onboarding document.
Best wishes, Arnaud Becheler _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/UQSQIMNC...