Option 1: Alliance stewardship of Boost
I believe this is important enough that it needs a thread of discussion split from the original at https://lists.boost.org/Archives/boost/2024/08/257347.php Some important details seem to have been lost in the conversation. I will summarize the Alliance position in a nutshell: The Alliance will become Boost's steward. Then, we shall assist the Boost Software Commons (a new non-profit created on March 1, 2024) to attain financial independence. Finally we will transfer the shared assets to this new non-profit. Also, I love Boost and I would like the opportunity to help it become a many-generational institution singularly driven to support library development. The message below is reposted in its entirety and without modification. --- I want to start by expressing my gratitude to Kristen, who kept an open and friendly line of communication with me for the last several months. It is unpaid volunteer work, difficult at times, and I appreciate her effort. As a passionate contributor to Boost, I am excited to see renewed growth and positive change in the project. The Boost Foundation has generously offered that the community may determine if the Alliance should be the steward of Boost’s shared resources. The term steward instead of owner is deliberate, as the former reflects the behavior which respects the Boost tradition of consensus-driven decisions. In this communiqué I would like to explore what option 1 looks like from an operational perspective (wearing my Alliance president hat) and then outline my opinion as the author of four Boost libraries. The Alliance is already the largest financial sponsor of the Boost project. Going with the first option means that our relationship to Boost would become formal. What would happen is this: 1. The Alliance becomes the registrant of the boost.org domain. This may take time, but effectively immediately after going with option 1, the Alliance shall fulfill our Domain Name Purchase Agreement under substantially similar terms including the launch of the Beman Scholarship Fund (if there is agreement). The Alliance shall reimburse the Foundation for any and all reasonable legal expenses incurred for both changes of domain ownership, including the estate fees. 2. The Alliance assumes all costs and responsibility to ensure that the boost.org domain registration does not expire, the SSL certificates are renewed and up to date, and that quarterly transparency reports are published to the mailing list apprising the community on the status of its registration. 3. The Alliance assumes all costs and responsibility for maintaining Boost’s cloud services (“Services”). This includes but is not limited to the wowbagger server, the new website, the new mailing list service, the existing mailgun account, and other services which may be required to support Boost’s infrastructure. The mailing list will be upgraded but continue to function as it is currently. Quarterly transparency reports will be published to the mailing list detailing the ongoing expenses and condition of these resources. 4. While the Alliance is the steward of the domain and cloud services, the content of the website and related web applications, such as the release building process, is controlled by the Boost GitHub Organization. Including but not limited to the repositories here: https://github.com/boostorg/website https://github.com/boostorg/website-v2 https://github.com/boostorg/website-v2-docs Changes made to these repositories will go through the existing pull request and review process, which requires community consensus. The Owners, defined as the set of users in the Boost GitHub Organization which have the Owner role, maintain the responsibility for determining consensus. 5. When the Boost community cannot achieve consensus, the responsibility for making a directional decision shall pass to the Boost Software Commons (“Commons”), a 501(c)(3) non-profit registered in Delaware on March 1, 2024, which is not controlled by the Alliance and whose board currently consists of Boost authors. The Commons is now in hibernation until it is needed. 6. The Alliance shall endeavor to help the Commons become capable of independently financing Boost’s infrastructure. The Services cost about $13,000 a year to run, excluding wowbagger and the downloads hosting costs. Our plans include: * Establishing a Boost Patreon * Sales of Boost-branded products at conferences and by mail * Soliciting donations from corporate and private sponsors * Optimizing the Services to reduce cost In all cases, proceeds from fundraising shall go directly to the Commons. 7. When fundraising levels reach the threshold necessary to finance the Services, or earlier upon request by the Commons, the Alliance shall transfer ownership of the boost.org domain to them. At the Commons’ option, the Alliance may continue administering the Services. Why The C++ Alliance? I believe that the Boost Foundation’s governance rules and board composition are simply not structured to put the best interests of Boost first, as can be seen from their own published minutes. The Boost project has been in decline for several years and the Alliance would like the opportunity to do something about it, in a way that is consistent with the project’s values. As our plans require significant financial investments (which we are happy to make), changes are needed. Option 1, Alliance stewardship of shared assets, provides Boost with the opportunity to refresh the foundations of the organization with new ideas, talent, and resources. It offers rescue from stagnation and the rare opportunity to restructure itself to better reflect the project’s changing needs from its inception 26 years ago. While I am excited at the possibility of realizing a dream to increase Boost participation, I am also mindful of the enormous responsibility this comes with. Fortunately I will not have to bear this alone, as there are many new and existing volunteers who are ready to support Boost going forward and ensure its longevity. Thank you for your support!
. The Services cost about $13,000 a year to run
Hi, Louis here. I manage the operations at the C++ Alliance. I’m writing to provide more details on the costs for hosting the new website. This is a snapshot of the costs for the month of June for all the services running boost.io: Google Cloud Platform $580 Kubernetes Engine $357 Compute Engine (Databases) $100 Compute Engine (mailman3 servers) $116 Cloud Memorystore for Redis $40 Networking $3 Artifact Registry $3 Cloud Storage Other $50 Amazon S3 Buckets $60 Fastly Website Caching $35 Mailgun service $1,344 Total for June To summarize, the annual projected cost for hosting the new Boost website is $16,128 per year. The board has tasked me with implementing a fundraising plan toachieve financial sustainability for the Boost Software Commons, to replace the loss of Foundation conference revenue and to ensure that Boost is not dependent on Vinnie’s donations for its infrastructure. To this end I have created a Patreon account. Donations are disabled for now, until the Boost Software Commons establishes the infrastructure to receive payments. https://patreon.com/boostorg Thank you, Louis Tatta The C++ Alliance
[...]
5. When the Boost community cannot achieve consensus, the responsibility for making a directional decision shall pass to the Boost Software Commons (“Commons”), a 501(c)(3) non-profit registered in Delaware on March 1, 2024, which is not controlled by the Alliance and whose board currently consists of Boost authors. The Commons is now in hibernation until it is needed.
Can you elaborate the rules/articles of association of this non-profit? Can the board only ever consist of boost library authors? If so, what would constitute a library author? Is this explicit in the bylaws? How would one get on the board of this organization?
On Mon, Aug 5, 2024 at 9:49 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
Can you elaborate the rules/articles of association of this non-profit?
Can the board only ever consist of boost library authors? If so, what would constitute a library author? Is this explicit in the bylaws? How would one get on the board of this organization?
I don't know, I am uninvolved. I think the details of its governance model should be worked out by the community, through a robust mailing list discussion. It has to work differently from Alliance and Foundation, obviously, as it must solve a different set of problems. Thanks
On 8/6/24 06:14, Vinnie Falco via Boost wrote:
The Alliance will become Boost's steward. Then, we shall assist the Boost Software Commons (a new non-profit created on March 1, 2024) to attain financial independence. Finally we will transfer the shared assets to this new non-profit.
How would the situation with Boost Software Commons be different from the current state with Boost Foundation? If it isn't, why would we switch to The C++ Alliance if the end result seems to be the same as what we have now?
On Tue, Aug 6, 2024 at 3:23 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
How would the situation with Boost Software Commons be different from the current state with Boost Foundation?
The Boost Software Commons will have these differences: * Focused only on Boost * Board mostly of active authors * Secure source of funding Foundation income comes from the conference and can go away from Boost. Commons is funded by Alliance and goes only to Boost. Foundation is always seeking to reduce Boost expenses. Commons can afford better things; cost-cutting is nice but not required. Securing the Commons' funding in the long term might be done through some kind of non-profit trust with an endowment, whose trustee is a law firm with written instructions. I'm researching this as a way to give the source of funding longevity. Thanks
Vinnie Falco wrote:
5. When the Boost community cannot achieve consensus, the responsibility for making a directional decision shall pass to the Boost Software Commons (“Commons”), a 501(c)(3) non-profit registered in Delaware on March 1, 2024, which is not controlled by the Alliance and whose board currently consists of Boost authors. The Commons is now in hibernation until it is needed.
I don't think this is necessary. Historically, outsourcing our decision making to some external entity has never worked, but even if it did, I don't see why we'd need a registered nonprofit for that.
On Tue, Aug 6, 2024 at 5:24 AM Peter Dimov via Boost
I don't think this is necessary. Historically, outsourcing our decision making to some external entity has never worked, but even if it did, I don't see why we'd need a registered nonprofit for that.
Someone has to do it since the Foundation will no longer be responsible. It doesn't have to be a non-profit, but since filling the Commons' board with authors is a recurring desire from stakeholders it would seem to be a good choice. There are probably other ways to do it, happy to hear your thoughts on that. Thanks
Vinnie Falco wrore:
On Tue, Aug 6, 2024 at 5:24 AM Peter Dimov via Boost
mailto:boost@lists.boost.org > wrote: I don't think this is necessary. Historically, outsourcing our decision making to some external entity has never worked, but even if it did, I don't see why we'd need a registered nonprofit for that.
Someone has to do it since the Foundation will no longer be responsible.
Why? The Foundation has never even tried to do this, and the previous such attempt (the infamous CMake announcement) has been a tremendous success.
El 06/08/2024 a las 15:13, Peter Dimov via Boost escribió:
Vinnie Falco wrore:
On Tue, Aug 6, 2024 at 5:24 AM Peter Dimov via Boost
mailto:boost@lists.boost.org > wrote: I don't think this is necessary. Historically, outsourcing our decision making to some external entity has never worked, but even if it did, I don't see why we'd need a registered nonprofit for that.
Someone has to do it since the Foundation will no longer be responsible.
Why? The Foundation has never even tried to do this, and the previous such attempt (the infamous CMake announcement) has been a tremendous success.
If the directional decision needs some shared resources, then the "entity" somehow needs to participate. Also, this type of "directional decision when consensus cannot be reached" feature comes from the Steering Committee times (which was formed in 2011), so we can't say it's not in the Boost tradition: https://web.archive.org/web/20141224160315/https://sites.google.com/a/boost.... However I agree that the outcome of such "directional decisions" is mixed. It failed with CMake, but we can say that SVN to Git migration (https://lists.boost.org/Archives/boost/2012/05/193493.php) decision was better handled. Best, Ion
On Tue, Aug 6, 2024 at 8:34 AM Ion Gaztañaga via Boost
El 06/08/2024 a las 15:13, Peter Dimov via Boost escribió:
Vinnie Falco wrore:
On Tue, Aug 6, 2024 at 5:24 AM Peter Dimov via Boost
mailto:boost@lists.boost.org > wrote: I don't think this is necessary. Historically, outsourcing our decision making to some external entity has never worked, but even if it did, I don't see why we'd need a registered nonprofit for that.
Someone has to do it since the Foundation will no longer be responsible.
Why? The Foundation has never even tried to do this, and the previous such attempt (the infamous CMake announcement) has been a tremendous success.
If the directional decision needs some shared resources, then the "entity" somehow needs to participate.
Also, this type of "directional decision when consensus cannot be reached" feature comes from the Steering Committee times (which was formed in 2011), so we can't say it's not in the Boost tradition:
https://web.archive.org/web/20141224160315/https://sites.google.com/a/boost....
However I agree that the outcome of such "directional decisions" is mixed. It failed with CMake, but we can say that SVN to Git migration (https://lists.boost.org/Archives/boost/2012/05/193493.php) decision was better handled.
The "directional decision" aspect IMO was never successful when it came to non-infrastructure decisions. I know this contradicts your examples, so let me explain the examples: The svn->git transition worked like this: * A couple of library developers implemented the process for doing the transition and provided a working model. * There were discussions on the list about that and the idea of the transition. * The community agreed to go to the committee and ask for a "thumbs up" to fully complete the transition. The cmake incident went like this: * There were lots of recurring discussions about cmake (the first one starting during the svn->git transition). * A couple of library developers started experimenting and implementing support of cmake for end users. * A couple of different developers, unaware (AFAIK) of that preliminary work, asked the Foundation to decide that Boost should move to cmake. AFAIK they didn't define what moving to cmake meant. But not sure as all that happened in the isolation of C++Now. Can you spot the differences? The successful case was to reaffirm what the community had already decided. The "unsuccessful" case was to usurp the community process. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
El 06/08/2024 a las 15:51, René Ferdinand Rivera Morell via Boost escribió:
Can you spot the differences?
The successful case was to reaffirm what the community had already decided. The "unsuccessful" case was to usurp the community process.
Understood, thanks for the context. Best, Ion
On 06/08/2024 14:51, René Ferdinand Rivera Morell via Boost wrote:
The svn->git transition worked like this:
* A couple of library developers implemented the process for doing the transition and provided a working model. * There were discussions on the list about that and the idea of the transition. * The community agreed to go to the committee and ask for a "thumbs up" to fully complete the transition.
I wouldn't remember it that way. My memory is that Dave asked for the help of a select few in writing the tooling to do the conversion because the Boost community had proved singularly useless in taking a decision, and he was going to impose a decision as BDFL after a great deal of wailing and complaint about there being any change at all. He then rammed it through fairly unceremoniously giving people very little choice about it.
The cmake incident went like this:
* There were lots of recurring discussions about cmake (the first one starting during the svn->git transition). * A couple of library developers started experimenting and implementing support of cmake for end users. * A couple of different developers, unaware (AFAIK) of that preliminary work, asked the Foundation to decide that Boost should move to cmake. AFAIK they didn't define what moving to cmake meant. But not sure as all that happened in the isolation of C++Now.
Can you spot the differences?
The successful case was to reaffirm what the community had already decided. The "unsuccessful" case was to usurp the community process.
Another way of looking at that is today Boost has almost complete cmake build support. In terms of **eventual outcome**, it has been quite the success, and the Dimov got that done incrementally and non-coercively. I'd therefore say the second case example is the more productive and less dysfunctional personally. Niall
Niall Douglas via Boost
I wouldn't remember it that way.
My memory is that Dave asked for the help of a select few in writing the tooling to do the conversion because the Boost community had proved singularly useless in taking a decision, and he was going to impose a decision as BDFL after a great deal of wailing and complaint about there being any change at all. He then rammed it through fairly unceremoniously giving people very little choice about it.
Hm, that's not how I remember it, and I was on the Steering Committee at the time. There was a heated Future of Boost session at C++Now where Dave used some strong words to express his frustration with a few Boost developers holding hostage the modernization and thus the future of Boost (or something to this effect). However, it was the Committee that then voted in favor of switching to CMake (and, no, Dave was not on the Committee). (FWIW, I abstained from that vote due to what I thought could be viewed as a conflict of interest: I would have voted against and at that time I was already working on build2, so it could have been viewed as me trying to undermine the competition. But, looking back, I should have voted anyway.)
On Wed, Aug 7, 2024 at 4:51 AM Boris Kolpackov via Boost
Niall Douglas via Boost
writes: I wouldn't remember it that way.
My memory is that Dave asked for the help of a select few in writing the tooling to do the conversion because the Boost community had proved singularly useless in taking a decision, and he was going to impose a decision as BDFL after a great deal of wailing and complaint about there being any change at all. He then rammed it through fairly unceremoniously giving people very little choice about it.
Hm, that's not how I remember it, and I was on the Steering Committee at the time.
There was a heated Future of Boost session at C++Now where Dave used some strong words to express his frustration with a few Boost developers holding hostage the modernization and thus the future of Boost (or something to this effect). However, it was the Committee that then voted in favor of switching to CMake (and, no, Dave was not on the Committee).
(FWIW, I abstained from that vote due to what I thought could be viewed as a conflict of interest: I would have voted against and at that time I was already working on build2, so it could have been viewed as me trying to undermine the competition. But, looking back, I should have voted anyway.)
Niall was referring to the svn->git conversion. And, I think, you are referring to the cmake work? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On 07/08/2024 13:41, René Ferdinand Rivera Morell via Boost wrote:
On Wed, Aug 7, 2024 at 4:51 AM Boris Kolpackov via Boost
wrote: Niall Douglas via Boost
writes: I wouldn't remember it that way.
My memory is that Dave asked for the help of a select few in writing the tooling to do the conversion because the Boost community had proved singularly useless in taking a decision, and he was going to impose a decision as BDFL after a great deal of wailing and complaint about there being any change at all. He then rammed it through fairly unceremoniously giving people very little choice about it.
Hm, that's not how I remember it, and I was on the Steering Committee at the time.
There was a heated Future of Boost session at C++Now where Dave used some strong words to express his frustration with a few Boost developers holding hostage the modernization and thus the future of Boost (or something to this effect). However, it was the Committee that then voted in favor of switching to CMake (and, no, Dave was not on the Committee).
(FWIW, I abstained from that vote due to what I thought could be viewed as a conflict of interest: I would have voted against and at that time I was already working on build2, so it could have been viewed as me trying to undermine the competition. But, looking back, I should have voted anyway.)
Niall was referring to the svn->git conversion. And, I think, you are referring to the cmake work?
I was referring to the svn->git conversion. Apologies, I should have clarified I meant Dave Abrahams not David Sankel. Niall
On Aug 6, 2024, at 7:33 AM, Niall Douglas via Boost
wrote: My memory is that Dave asked for the help of a select few in writing the tooling to do the conversion because the Boost community had proved singularly useless in taking a decision, and he was going to impose a decision as BDFL after a great deal of wailing and complaint about there being any change at all. He then rammed it through fairly unceremoniously giving people very little choice about it.
I'm sorry, I can't let this stand. It's basically slanderous. It should all be in the public record, regardless. I was never a BDFL, and was never in a position to impose a decision. I asked for help in writing tooling to do the conversion, it is true. Not because the community was unable to decide about anything (tooling can't possibly help with that), but because the problem was hard. The problem was hard because there was a great insistence at the beginning on meaningful preservation of all branch history in SVN (in the end, after all that work, IIRC many people wanted to delete the old branches!) At some point we announced https://lists.boost.org/Archives/boost/2013/05/203367.php that the conversion was ready for review, by which we meant we were collecting feedback on the results. That lasted a couple months and when the kinks were worked out Beman started a thread https://lists.boost.org/Archives/boost/2013/10/207803.php to discuss a switchover schedule. It was all done by consensus.
On Sat, Aug 17, 2024 at 11:50 AM Dave Abrahams via Boost < boost@lists.boost.org> wrote:
...It should all be in the public record, regardless...
This brings up an interesting topic. In the last several weeks I've been studying the public records and it is not always clear to me the order of events or the exact dates. For example, was Boost founded in 1998 or 1999? I only started contributing in 2017 so I have no memories to call upon here. A personal project of mine is to construct an unbiased and accurate historical record of Boost for people who have joined the project more recently to understand the context of things and also the rationale for why things were done a certain way (or in some cases to understand why certain decisions may not have worked out so well later). I guess what I'm saying is that it would be nice if some of the O.G. Boost folks could sit for an informal interview and help offer more detail on the early years of the project. Thanks
On Tue, Aug 6, 2024 at 6:13 AM
Why? The Foundation has never even tried to do this, and the previous such attempt (the infamous CMake announcement) has been a tremendous success.
I can't claim expertise to know whether breaking deadlocks is a function necessary for the Boost project. However, since the Foundation will disavow this responsibility when going with Option 1, it seems prudent to cover bases. Of course, if you feel this is unimportant or even detrimental we could explore what not having it looks like. However, note that for whatever non-profit ends up as the steward, it will be impossible to prevent it from assuming unimportant or detrimental functions, even stacked with Boost authors. Bureaucracies like to do things (for example, WG21 designing their own libraries), and telling them they must not do things tends to fall on deaf ears. Furthermore it is difficult and sometimes impossible to structure a corporation's bylaws in a way to prohibit certain things, because attempting to do so runs afoul of laws regarding corporate governance. Future board members can always undo prior actions. Thanks
On Mon, Aug 5, 2024 at 8:14 PM Vinnie Falco
I would like the opportunity to help it become a many-generational institution singularly driven to support library development.
All of the Alliance activities are designed to drive up the number of volunteers and stabilize the project. The new website, a new logo (yes I know some people hate it), brochures and shirts at CppCon, Boost-related talks, supporting authors directly through the Staff Engineers program, continuous integration, better documentation, and IT support. Boost needs this because there is currently nothing in place to bring in new people to replace the older ones who depart the project for various reasons. Debates about what precisely needs to be done are all well and good, but action is better. To demonstrate the significance of this problem, I have written a script which counts the number of unique first names that have committed to any Boost library repository in a given year. This is what that graph looks like: [image: ua.jpg] The bash script is here: https://gist.github.com/vinniefalco/81a31b26b8bc9aa371ace8d065eec852 And this is a Google sheet with the output. I manually smoothed 2006 because it was an outlier. https://docs.google.com/spreadsheets/d/1BENN9T5bzX_aZp0FhlsGW5kcSuoTFm8M7oMJ... The Formal Review Process is a key social technology, and it works best when it has higher participation rates. Growing the number of volunteers or at least keeping the number from diminishing is important to support this. 2012 marks the transition from SVN to Git I believe. Beman retired in 2018 and passed away in 2020. The COVID epidemic was also in 2020. I am not sure if this affected the number of unique authors. If these calculations are correct, it indicates a dwindling supply of authors and by extension reviewers, review managers, and such. I hope maybe someone can find a big flaw with my script which invalidates the shape of the graph. Thanks
participants (10)
-
Andrey Semashev
-
Boris Kolpackov
-
Dave Abrahams
-
Ion Gaztañaga
-
Klemens Morgenstern
-
Louis Tatta
-
Niall Douglas
-
pdimov@gmail.com
-
René Ferdinand Rivera Morell
-
Vinnie Falco