Maybe "fork" was bad wording considering that the code is not derived from boost. Still, as it serves as a boost replacement, I am saying that I would love to see improvements you put there to be put into boost instead, so they serve a larger audience.
This is just a question of priorities: I want to release CppCMS - I need stable boost-like library.
Simple: 1. You release the CppCMS source (AFAIR, it is meant to be open source), people download the source, compile it, compile their applications (both against their installed boost). So it will work as they will have the same boost ABI in both components. 2. (optional) You release binaries compiled for the distributions you use. They will be compiled against the boost version shipped with that distributions, so people running the same distribution can use them and avoid compiling themselves. 3. (once CppCMS gains popularity) People running other distributions release unofficion binaries compiled for their distributions. The same as in (2) applies. 4. (once CppCMS gains even more popularity) Distributors ship official compiled builds of CppCMS for their distributions. The chances for (3) and (4) might be significantly reduced once CppCMS depends on an extra library which implements functionality that could instead be obtained from boost with much more peer review improving it.
1. I can't fix all boost on-my-own.
Me too. So if I find a bug in boost, I publish it. Others do the same. The effect is a boost with very high code quality (I think it happened only once for me that deploying software was slightly delayed due to a boost bug).
So once boost "stabilization" would be started as official part of boost I'll be the first who helps.
Look for a distributor who maintains ABI compatibility and send them you resume. If they lack someone who is expert in boost ABI engineering and you can fill that need, they will probably hire you. Best regards, Isidor