Idea: Boost Software Foundation?
Hi Everyone, I have been watching the passionate debate about how to go about achieving the following: 1. Make Boost less monolithic and more open to contributions 2. Make Boost easier to distribute and support 3. Make Boost better but less complex and more manageable Someone mentioned the "incubator" idea and now that I think about it more I think this model works very well for Boost. Let me try to draw some parallels between the Boost C++ Library and the Apache Software Foundation: 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. 3. As an entity, the only difference I see between Apache and Boost are that: * Boost is a volunteer-backed, non-foundation backed entity, while the Apache Software Foundation is legally a non-profit non-stock organization. * Boost does not have resources that "it" owns while ASF employs people in different capacities. * Although the Boost Software License and the Apache Software License are both OSI approved, there seems to be no legal team dedicated to ensuring that the terms of the licenses (and the contributions made by contributors) are "properly" applied. I don't want to instigate an "uprising" here, but I for one would like to see a Boost Software Foundation whose main task would be to further the Boost-licensed projects, and lends its name to signify the high quality and organized peer-reviewed and meritocracy-driven C++ application and library development for the betterment of the C++ language and vendor/implementor/library-author community. And then to see the Boost Software Foundation have a formal means of having projects "built for Boost-inclusion" be drawn into an umbrella project to become "incubated and developed with Boost Quality in mind". If I understand how Apache projects are run, it appears that: * A project manager is assigned/nominated by the community to represent a sub-project in the bigger Apache project. * There are official developers who have commit access to the repository; developers who want to become an official developer of the project signs a contributor agreement which states in no uncertain terms that they agree that their changes committed to the repository are licensed under the Boost Software License. * To become a "committer" to the project, you have to be asked by official developers or nominated by peers based on your contributions in the form of patches or pulls from your "fork". I do not see why this model should not work for Boost granted that some people already take the libraries they maintain as their full-time (or almost full-time) projects (Boost.Thread, Boost.Spirit/Fusion/Phoenix). And because of the decentralized nature of this model, the only "review" that has to happen is whether a sub-project should be incubated, and whether projects in the incubator are deemed "mature" enough to become full-blown Boost.* projects. One other idea about distribution: the biggest hindrance I think is the lack of a "centralized" or "repository-like" location from where released versions of a library can be pulled easily. Haskell has Cabal, Perl has CPAN, Debian has official 'apt' repositories, Ruby has multiple Gem foundries, Python has the Cheese shop (?). Although SVN is centralized by nature, it's not the best means of distributing releases that can be kept in-sync from various locations. Maybe the Boost community might be able to come up with a similar solution and contribute towards building a C++ package-based solution to distributing libraries in a cross-platform and scalable manner? I hope this helps. I personally have no idea how to get a Boost Software Foundation up and running but I do want to participate in that effort in a substantial manner if other people think that would be a good idea and would like to make it happen too. Have a good day everyone, that's my $0.02 worth. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
On 11/25/2009 09:32 AM, Dean Michael Berris wrote:
Hi Everyone,
I have been watching the passionate debate about how to go about achieving the following:
1. Make Boost less monolithic and more open to contributions 2. Make Boost easier to distribute and support 3. Make Boost better but less complex and more manageable
Someone mentioned the "incubator" idea and now that I think about it more I think this model works very well for Boost.
[...] That sounds like an excellent suggestion to me. Stefan -- ...ich hab' noch einen Koffer in Berlin...
One big advantage of having a foundation is that it makes the job of raising money easier, especially if you can get the foundation approved as "general interest" (tax deduction...). However I don't think having a formal, legal definition makes the organization less monolithic and more flexible. The way you are organized is IMHO orthogonal. -- EA
On Wed, Nov 25, 2009 at 10:40 PM, Edouard A. <edouard@fausse.info> wrote:
One big advantage of having a foundation is that it makes the job of raising money easier, especially if you can get the foundation approved as "general interest" (tax deduction...).
However I don't think having a formal, legal definition makes the organization less monolithic and more flexible. The way you are organized is IMHO orthogonal.
I would tend to disagree with the assertion that organization would be orthogonal to the project. Let me state why I would disagree: 1. Having an organization dedicated to a project gives the project a clear direction and the mechanism for it to deliver in an organized manner. Right now the adhoc process of review and inclusion yields the very "beast" (used in an endearing manner) that is the monolithic Boost C++ Library. If you organized each sub-project as a sub-organization or sub-project of a bigger quality effort, then you can deliver what people have been looking for which are modular releases of Boost libraries, more open to contribution on a per-project basis, easier distribution, etc. 2. Because of the fund-raising capability introduced by having a Boost Software Foundation, you can then convince industry players to support an organization dedicated to advancing the ideals of the original project. Less abstractly it's easier to convince compiler vendors, third-party support providers, and users in general to fund an effort for advancing C++ language, application, and tool development. 3. What a formal organization can provide that a loosely knit group of volunteer developers+users can give is focus that is otherwise lacking to deliver the utmost quality we the users are looking for. By having a single organization represent the Boost community of users, developers, and supporters it can focus on the issues that need addressing: things like documentation, project management, release management, promotion/marketing, etc. These are the three reasons I would think having an organization like a Boost Software Foundation would do the Boost C++ Library project a whole lot of good on top of the good that it itself is already able to deliver. I HTH. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
Dean Michael Berris wrote:
On Wed, Nov 25, 2009 at 10:40 PM, Edouard A. <edouard@fausse.info> wrote:
One big advantage of having a foundation is that it makes the job of raising money easier, especially if you can get the foundation approved as "general interest" (tax deduction...).
Boost has this ability already via the Software Freedom Conservancy, which is currently holding e.g. some proceeds from the Google Summer of Code. -t
You can do 1. without creating a formal organization, 2. I agree fully, 3. That's where I disagree, although I think the idea is good, I think it's a bit naive to believe that the day you create a foundation it's going to be better organized "because it's a formal structure". It's just going to take immense amounts of efforts, blood and energy. But I think it's worth it. -- EA
On Wed, Nov 25, 2009 at 11:14 PM, Edouard A. <edouard@fausse.info> wrote:
You can do 1. without creating a formal organization,
Yes, but it would be really hard to do -- like what's happening now. Having that one organization that will *full-time*, not on a pure volunteer basis (i.e. with staff whose job it is is to manage, provide/maintain resources, etc.) you would have a better chance of "scaling" the Boost project.
2. I agree fully,
Cool. :)
3. That's where I disagree, although I think the idea is good, I think it's a bit naive to believe that the day you create a foundation it's going to be better organized "because it's a formal structure". It's just going to take immense amounts of efforts, blood and energy. But I think it's worth it.
It's not "the day you create a foundation", but more like "the day you have full-time paid well-oiled organizational support for the project as a whole". Imagine if you had on staff: * Technical Writers -- tasked to churn out "professional quality" documentation on all technical matters in the community with regard to discussions on the mailing lists, updates on libraries, documentation on a per-project basis, etc. * Release Managers -- whose full-time job is to track down the people associated with the resolution of issues slated for the release being developed, to make sure that the quality of the projects are up to Boost spec, that testing results are gathered, and that releases are done in an orderly and managed fashion. * Evangelists -- whose full-time job it is to promote the use of modern C++ practices, adopt Boost in C++ projects, and basically get the word out that Boost is here and that it's now a "serious project" because we're really serious in delivering the quality libraries that C++ developers seem to want very much. * Project Managers -- whose full-time job it is to manage the delivery of "promised" features and releases from individual sub-projects under the Boost Software Foundation umbrella. * Test/QA Managers -- whose full-time job it is to set up, maintain, and monitor dedicated testing/development resources owned by the Boost Software Foundation. No more "volunteer" testers, just official test machines/configurations and officially supported platforms. Think of the level of organizational support Boost projects can enjoy, and the kind of quality that Boost Library and Tool developers can deliver because of the above. I don't think a pure volunteer, mostly part-time, organization/effort can possibly dream of delivering without at least a handful of dedicated resources. I personally think it's worth it too, and I think in that point we don't disagree. ;) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
On 11/25/2009 10:14 AM, Edouard A. wrote:
3. That's where I disagree, although I think the idea is good, I think it's a bit naive to believe that the day you create a foundation it's going to be better organized "because it's a formal structure". It's just going to take immense amounts of efforts, blood and energy. But I think it's worth it.
Compare it to what boost.org is right now. The question is how to get away from the huge monolithic effort that boost.org is right now, without loosing all the benefits, among which there are: * A vibrant community * Project hosting (with all the usual infrastructure, and portal bits) * Operating under a single administrative (and to some extent legal) umbrella Getting there doesn't have to be a very disruptive process, and thus doesn't need to "take immense amounts of efforts, blood and energy". It could very well be incremental, over a couple of years. What is important, though, is to develop a shared vision of where boost.org should go, to have everybody work towards the same goals. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Just to make things clear, it's not because it's difficult we shouldn't do it. I really think it's a good idea, just wanted to remind that's it's more difficult than you think, and even the degree of difficulty I've got in mind when I say that is, I think, below the truth. It's better to go prepared because there's nothing that destroy enthusiasm better than an unforeseen major difficulty. -- EA
On Wed, Nov 25, 2009 at 11:46 PM, Edouard A. <edouard@fausse.info> wrote:
Just to make things clear, it's not because it's difficult we shouldn't do it.
Agreed. :)
I really think it's a good idea, just wanted to remind that's it's more difficult than you think, and even the degree of difficulty I've got in mind when I say that is, I think, below the truth.
Definitely. It's a challenge, and if enough people agree to do it, a major effort. Doesn't mean it's impossible nor it shouldn't be done.
It's better to go prepared because there's nothing that destroy enthusiasm better than an unforeseen major difficulty.
Indeed. Thanks for sharing your thoughts! :) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
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
On Wed, Nov 25, 2009 at 11:54 PM, Matt Chambers <matthew.chambers@vanderbilt.edu> wrote:
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.
But you already do this when you're using multiple libraries anyway right? I guess the monolithic "single release" can still be pulled from different sub-projects like how Boost.Spirit is developed in Sourceforge then brought into trunk when it's stable enough to be part of the daily (?) test cycles. This way you the user can have a choice of using either the latest Spirit with an older Boost release, or the latest Asio release with the latest Boost release without using the "pre-bundled" Asio or Spirit that do come with the monolithic Boost release. There could be an integration phase, where a monolithic Boost release can pull the latest release among all the sub-project libraries and then make changes so that things don't break when users do choose to use the single monolithic release. This can be a community effort, meaning anybody (not a maintainer of the library being brought into the monolithic core) can make sure that the releasable version of Boost that people can download as a single bundle will work "out of the box". Then these changes can be submitted "upstream" into the sub-projects. This is how Linux works with distributed development repositories, where anyone can submit patches upstream to be part of a release that Linus "sanctions" (with the appropriate copyright attributions) or release their own version of Linux with their own changes. I can definitely imagine a git repository that BoostPro manages, one that Spirit publishes, an Asio git repository, <insert subproject git repository here>, and a "canonical" Boost git repository that pulls from the many different git repositories, stabilizes the "trunk" (AKA "master") and from which every other subproject will pull from. That said, anybody then can make a fork of the Boost git repository or any other subproject repository, make their local changes, and then request that some patches from your local repository be pulled by the project or submit patches to the maintainer of the repository you forked from. You can publish your own version of Boost but not call it an official Boost release while you're at it too.
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).
Which is where the community effort can come in. If you want to be part of the development for example of Boost.Serialization, then you fork the Boost.Serialization repository (assumes that we're using git on github), make your changes to your own repository, and then ask the maintainer of Boost.Serialization to pull from your fork. If you want to be part of the community effort to release a monolithic Boost release, then a release manager can take the latest stable release (or master, depending on the policy/strategy) of the subprojects and then integrate them into a single repository from where you can fork from and help stabilize the implementation, then ask for a pull from your repository be done. If someone would like to maintain for example a Boost 1.41.x line and take the effort to maintain a git repository that supports the 1.41.x release, then it should be entirely possible to do so by allowing sub-projects to evolve outside the monolithic Boost release on their own. Then it can be a community effort to allow submissions in a fashion that is still controlled/managed by the maintainer (the maintainer can choose to not pull from a fork). Now the foundation comes in to fund the operational expenses of paying a release manager for the time he spends working on release management, for project managers that track the progress of either individual projects/sub-projects, for publishing/hosting the website and the issue tracking system, and for the maintenance and operation of build/testing machines. All the coding is done by the developer community in an open fashion. Here you get: * A monolithic Boost release still with its own development/release schedule * Multiple subprojects that are encouraged to grow and evolve outside of the monolithic Boost release * An "organized" fashion for letting community contribution easier I hope this helps and makes sense. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
participants (5)
-
Dean Michael Berris -
Edouard A. -
Matt Chambers -
Stefan Seefeld -
troy d. straszheim