On 3/24/2010 1:11 AM, Tom Brinkman wrote:
Thanks John.
Well, for the most part, I agree with the larger point that you have made.
However, for some reason, people don't apply that same standard to boost. Because boost is open-source, the source code is obviously available so people will invariably take a peak at it.
If what they see scares them, and then they find out that the library may in fact have only one one active maintainer, it can be a real source of concern.
Its strange though, because MPL is the most difficult to understand library of them all, but in the view of many it is boost's most important and valuable contribution. I think that we all have made an exception for that library, considering its overall importance. Others probably feel the same for some of the other core boost libraries. Because they are so important, they would get fixed eventually, by someone other than the core developer, if it ever became necessary.
Its all the other non-core boost libraries that people worry about. A big complex template laden library, in a non-critical vertical, with only one active maintainer, in source code that appears to be completely unmaintainable.
This was a point I made in another thread. From the end-user perspective a Boost library is great as long as the feeling that there is someone maintaining the library exists. I do not worry about the internal complexity of a Boost library as long as the documentation is good enough to allow me as an end-user to use it. I think there are Boost libraries where the original author of the library, for very understandable reasons, no longer actively maintains it or is responsive to problems, bugs, suggested improvements for the library. In that case I think it is important that someone else take over maintenance of a Boost library. It is way too onerous to expect even the good C++ programmer to have to understand a Boost library internally to be able to use it. That's why it is important that someone is actually still maintaining a Boost library even if the problems regarding it may be small to virtually non-existent. As for who might be willing to take over maintenance of someone else's Boost library I think there are enough skillful people who follow Boost that if there were a policy by which a new maintainer were to be looked for when an original author of a library no longer wishes to maintain it, another person would be found. I can not imagine a developer willing to maintian a library forever but I can imagine others willing to maintain it during its realistic usage period. That's why I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library. I think that even currently there are a number of Boost libraries where the original author pays little to no attention to it or attempts to fix bugs, address problems, and listen to suggestions regarding the library, and it would be wise for Boost to transfer "ownership" of the library to somebody else.