As Marshall announced that the formal review of my library has started I'd like to provide some information which is maybe helpful for those interested in submitting a review. * While Boost.Process is currently my library I can't take all the credit. Development of Boost.Process started back in 2006 and was initiated by others. I picked up the library in 2008 and greatly benefited from the work which had been done before. Even after 2008 other developers actively worked on forks of Boost.Process and contributed a lot of ideas and implementation details. I basically tried to collect and merge all the work which was done in the past five years. (But that doesn't mean I didn't contribute any code: I added for example support for asynchronous operations. :) * As development started five years ago, as we had countless of proposals how Boost.Process should look like, as we had many developers working on various Boost.Process drafts and even more developers contributing to discussions on the mailing lists, it's not always easy to understand why certain decisions were made and how we ended up with today's library. Sometimes even I don't know - for example because I didn't write and never touched some code (I think the class boost::process::detail::systembuf is a few years old and has never been changed) or because we were busy thinking about bigger problems and didn't notice some minor issues (I think it was Vicente who recently asked why the Context parameter is not passed by reference to boost::process::create_child()). * We had rather different Boost.Process drafts in the past. First there are many process management features which are unfortunately platform-specific but still too important as if you can simply ignore them. Second there are many features implemented in Boost.Process which could be useful by their own. The current solution for the first problem is that Boost.Process only supports platform-independent features and provides extension points to plug-in support for platform-specific features. This should make it possible to set a realistic goal of being feature complete at some point in time and to avoid overloading the library by trying to support too many platform-specific features. For the second problem no solution exists. That means it's currently not easy to use parts of Boost.Process outside of the library. For example Boost.Process defines a class boost::process::behavior::pipe to create a pipe. However the class is not designed in a way that it is intuitive to use outside of Boost.Process. * As Boost.Process tries to support platform-independent features, designing the library comes down to identifying cross-platform concepts and where and how to provide extension points. The implementation itself is not that difficult. You won't find any clever C++ tricks in Boost.Process. Compared with some of the other Boost libraries it's a pretty normal object-oriented library. If you want to learn something new in C++, it's probably not worth looking at the implementation. :) * Apart from the design and implementation of the library, there is room for improvement in the documentation and when it comes to platform support. I had recreated the documentation in Quickbook which as far as I know is the preferred documentation format for Boost. As I had to recreate it, it can surely be improved and extended. As there have been changes in the library again and again, I'm actually waiting for the right moment to update the documentation. :) Regarding compilers and platforms: I tested Boost.Process with Boost 1.45.0 with VC++ 2010 on Windows 7 and g++ 4.4 on Debian 6.0 on the weekend. I'll see whether I can also support the library on Cygwin and Solaris 11 Express (had a compiler error with Boost.Asio on Cygwin and couldn't easily find packages for development tools for Solaris 11 Express). As some MinGW users had been interested in the library, I also appreciate feedback for this platform (and of course for any other). * The main reason why I proposed the library for a review is not that I think it's all perfect. My impression though is that there is tremendous interest in a process management library - at least that's what I think when I look at the discussions we had on the mailing list and at the many emails I got with questions about Boost.Process. I would appreciate more code contributions and of course more feedback and hope that an official Boost.Process library could foster future development. Boris