But why not make a boost trunk clone on gitorious.org and start a boost stable branch yourself? It would probably need some documented update policy (like: sync down from trunk every maybe 2 or 5 years, and in between only ABI-neutral changes are imported and bugs fixed) so users will know they will not be caught in a fork, but have a defined schedule on when to expect new features from mainline boost coming in. But then I could imagine interesting contributors or at least people providing feedback coming along themselves.
There is three major issues with this approach: 1. It is fine as long as I use one working version of boost and it has no bugs. Because once I need bug fixes, it would be non-trivial to fix them in the state boost today is. Without correct code preparation it maybe impossible to fix bugs without breaking ABI. So it is no-go solution. 2. Some boost ABI code may be affected by defines. For example if user defines debug smart pointer option just to see how it works in its own code it may crash the application because library sees somethig else. 3. Boost is configured mostly with defines. So upgrade of compiler version for gcc-4.3 to gcc-4.4 may break ABI just because some new feature comes and something is changed in class layout. So this not simple thing to do. Example: In Boost I changed shared_ptr a little to prevent these issues: 1. I removed debug hooks from shared/weak_ptr's 2. I moved sp_counted_base code to implementation and added mutex instantly to it (if I even do not use it). So I can change its behavior without affecting the rest of the code. Artyom