However, there is no easy way of telling which libraries are active and which are unmaintained. Do I invest time in learning and using a library that is unmaintained, or do I adapt to a newer library that is close enough to be useful and more likely to be updated with time? That's a good point, to a first approximation you could look to see when
the last commit to master was (not very user friendly of course), I wonder if that information could be automated? Or would it be swamped by admin changes that aren't "real" releases? In fact the more I think about this, the harder it is to tell, I bet there are many libraries that are mature enough that they get little or no maintenance - and frankly don't really need it. They worked fine yesterday, they'll work fine tomorrow. C++11/14/17 isn't going to change that. Perhaps in some cases move-aware constructors would be a useful addition, but that may be all. You could look at Trac to see if there are large numbers of open issues - but you know what, old libraries accumulate "unfixable cruft". It doesn't necessarily make them broken/unmaintained/obsolete. Speaking only for myself, I generally prefer to leave these open rather than gratuitously close as "won't fix", even though they will *probably* never be fixed. Maybe we need some kind of survey, say 2 libraries a week, skip any that are obviously maintained and then ask the questions: * Is the maintainer still around? * Does it matter - is it accumulating issues? * Does anything need doing to bring it into C++11/14 land? * Has it been obsoleted - which is to say, does it make sense to use this in new code? I'll finish by pointing out one lib that fails on the last question - call_traits - in fact I might go off and submit a documentation PR now... Thinking out loud yours, John.