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