Dean Michael Berris wrote:
1. As a project, Boost and Apache try to (and I'd like to say both do) deliver high quality open source components under a liberal and commercially friendly license. Boost has many sub-projects that are worth naming like Boost.Build, (Boost.?)Quickbook, BCP, and Boost.Jam (although a little stagnant IIRC). Maybe treating other libraries as sub-projects that have a publicly-accessible and easily "forkable" repository would be a good thing. Git and Github come to mind.
2. As a software distribution, Apache has decentralized the release management of the libraries and software projects under its umbrella. This means sub-projects can depend on specific version releases of other sub-projects instead of making sure that there's only one release that bundles everything together.
If you want to compare with Apache, the Boost libraries are akin to the Apache Portable Runtime, not the Apache project as a whole (which is far more application-oriented than library-oriented). So it's not clear to me why you would want to split up libraries like Apache splits up applications. Sure, the Boost scope is bigger than APR, but not terribly so. I think if the libraries were split up as separate releases, that would shift the burden of synchronizing them to the library users, which seems like a very bad idea to me. It would make it easier in some cases to adopt a single library from Boost while leaving the others, but then trying to add more libraries begins the synchronization issue (e.g. some user has been using a recent version of library A; they want to start using library B, but library B's current release depends on an older version of library A, while the user depends on the recent version of A). -Matt