As development of Boost.Process started ages ago and it seems like we still don't get anywhere I'd like to ask why this is so. I do see very valuable feedback every time Boost.Process is discussed. But at the same time some concerns are raised again and again no matter how much the library was changed since the last discussion. So here's my attempt to explain why we struggle so much: As Boost users we want platform-independent code and convenient high-level interfaces. As C++ developers we want efficient implementations and flexibility. It seems like as if these goals are contrary for a process management library. And in my opinion the very different system interfaces are the main reason. If Boost.Process has platform-independent code only, developers will complain about the lack of flexibility. If Boost.Process provides flexibility with Windows and POSIX APIs, developers will complain about #ifdefs and writing code twice. If Boost.Process supports high-level concepts, developers will complain about inefficient implementations. If Boost.Process supports only what can be implemented cross-platform efficiently, the library is so small that it's practically useless. And if Boost.Process supports a compromise like generic code with extension points, developers from both sides will complain about not generic and flexible enough. Could it be that goals are too different? Do we need multiple Boost.Process libraries? Boost.ProcessForWindows, Boost.ProcessForPOSIX, Boost.ProcessForEveryone? Back to generic classes, Windows classes and POSIX classes? Efficient implementations but very few features in the generic classes and very different APIs between the Windows and POSIX classes? If this sounds good does it help anyone? Would you use such a library or simply call system functions directly? After all it's not that difficult to create a child process without a library and you would get full flexibility without an extra layer from a library? Comments greatly appreciated! Boris