If I had nothing but free time, I'd investigate using CMake instead of, or in addition to, Boost.Build. From the website:
CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.
With CMake, we could deliver makefiles and vc project files, so people can use their own build environments instead of having to learn ours. I think this would remove a barrier to Boost's adoption. This article describes the experience of the KDE team switching to CMake:
This would be great. A significant number of OSS projects already use CMake (in addition to kde : ITK/VTK, in particular, are close to my heart). It also supports XCode projects, which would simplify the generation of Boost frameworks for OSX developers...
FWIW, quickbook is merely a front end for existing external tools (docbook, doxygen, fop). Nobody actually has to use quickbook -- they could program directly to these lower level tools, and BBv2 supports that. But the flakiness of these tools, and the length of the toolchain, has been a constant source of trouble for us.
Fortunately, there is no mandate on the specific format of documentation for Boost libraries. However, I agree that it is desirable to have some level of consistency of documentation format. I know that Steven spent a significant amount of time getting quickbook to work for the Boost.Units documentation, so I would agree that flakiness is a problem. Given that writing documentation is generally the least favorite activity in any given software project, adding even small hurdles is clearly undesirable... Matthias