I can address this from the commercial user's point of view. I have a long history in open source and am currently working for a well-established Windows-only ISV. Boost has its own way of doing things that is poorly coupled into my environment. Adapting a new release of boost into my build scripts to evaluate it is painful and time-consuming. I have my own release cycle that has periodic windows for non-emergency updates of tools and other third-party components. If your two-week beta period happens to fall in that interval I'm likely to work with it, otherwise it's going to be whatever is stable. We have close to five million lines of our own code, a dozen or so third-party libraries of all descriptions, tools from several different vendors, and we test against every Windows version since NT4. If there were a well-maintained cookbook for testing the beta against my build I'd give it some attention. But it took me a week of pulling my hair out over the bjam / boost build documents to get it wired into my build the last time I upgraded. I'm not looking forward to doing that again, and my boss has other ideas about how I should spend my time -- up to the point where we need something from the new release. Having worked the beta cycle from both sides in the commercial software world, I can tell you it never works very well. When well-planned, well-resourced, and well-executed it can be useful. But it is seldom as useful as one might hope or imagine it could be. As for breaking existing use cases, this will cause us to stay at the last release that meets our needs until the beginning of a new major release cycle on our side, unless there's some other feature that compels us to deal with the breaking change mid-cycle. We're not using that much from boost so we'd not even notice many breaking changes but if one hit a feature we're using widely we would not / could not consider adopting that release mid-cycle without some serious bug or similar justification compelling it. Our products are used in stringently regulated environments for life-critical purposes. We aren't permitted to change anything without a good reason. The beginning of a major release cycle is the only window we have for big infrastructure changes. That's an unusual constraint but every user will have some unusual constraints on their resources and/or freedom of action. Boost competes for that limited pool of beta-participation time with all the other tool and library vendors. Open-source status gives you champions in the development pit but it doesn't change management's priorities. -swn