Dear Boost community, the formal review of candidate Boost.OpenMethod has taken place between 28th of April and May 7th. I have received 6 reviews in total. Four of the reviews recommended unconditional, and 1 conditional acceptance. One reviewer recommended to reject the library. The reviews came from: - Joaquin M López Muñoz, - Christian Mazakas, - Ruben Perez, - Yannick Le Goc, - Klemens Morgenstern, - Andrzej Krzemienski. Also, several people have given insightful comments but did not provide a review. I would like to thank all of the people who took their time to write reviews or participate in the discussions. Your effort was very important and valuable. The outcome of the review is that Boost.OpenMethod is ACCEPTED with some CONDITIONS. 1. The convenience header <boost/openmethod.hpp> should be changed to not introduce identifiers to the global namespace. Reviewers suggested several alternatives to that: either moving those global entities into an alternative header, or put them into a dedicated namespace which users could use via using namespace. 2. The library should not choose an arbitrary ambiguous overrider. Virtually all reviewers have expressed strong dislike for this behaviour. The default should be an error. More lax overrider selection may be provided as an option. 3. The library's documentation should be improved in several areas: * The concepts used by the documentation should be explained early on and more thoroughly. * The library should not claim to implement N2216, as it diverges from it significantly. Instead it may remark on being inspired by it. * Better explain potential platform-specific limitations of certain use cases (runtime loading of shared libraries) and error conditions. In addition, I want to discuss several criticisms that have been expressed during the review. One is that essentially the library doesn't solve a problem that is worth solving. That is, you never need an open set of types combined with an open set of operations. I believe that 10 years of library's use should mostly dispel such concerns. I personally have also encountered such a situation in my practice. The second criticism is that the flexibility of the library comes with higher chance of programmer error, as some usual safe guards go out the window. I can attest that in "many types, many operations" situations alternative approaches are comparably error-prone. It seems to me that this is largely inherent to the complexity of the problem. My advice to the author is to highlight dangerous situations, so that potential users can better evaluate if the added flexibility is worth it. Thanks to Jean-Louis Leroy for submitting this library to Boost. And thanks again to the reviewers and everyone who provided feedback, who ultimately made this review possible.