In your review do disclose any affiliation to either the C++ Alliance or Boost Foundation groups. Please state any connection you have to Boost (developer, user, package manager etc.)

I was a staff engineer for the C++ Alliance for over a year until the end of 2023. I've been a boost developer since process has been approved in November of 2016. This is my review: Since we're not reviewing a software library and thus no implementation is available, I think past experiences also can be taken into account as a basis of future expectations. The standard review question also doesn't help a lot here either, so I'll use my own for readability. What is your evaluation of the proposal? What is your expectation of its implementation? What is your expectation regarding the usefulness of the proposed changes? I'll be denoting the C++ (A)lliance as (A) and the (B)oost foundation as (B). # What is your evaluation of the proposal? A) The alliance proposal shows great understanding of what makes boost great and different. It also analyses the current state and problems of boost quite accurately and outlines a well thought out solution & vision. I especially appreciate the clear agreement that does give a workable governance structure based on an established model (the Software Freedom Conservancy) and includes a way to move on without the C++ Alliance. That is Boost is not locked-in with the C++ Alliance. That means it's neither owned nor controlled directly by the C++ Alliance. B) The Boost Foundation's proposal doesn't show a deep understanding of Boost. The review process is mentioned as a sidenote, the license isn't. There is little boost specific. I also have a hard time taking its values seriously, as I have not experienced any transparency, consensus building or honoring the governance process. The whole drama with the website mainly consisted of the Boost foundation ignoring the majority opinion, trying to manipulate the governance process of boost and being utterly intransparent of what happened behind the scenes. The latter usually consisted of public response to private emails. The Boost Foundation is made up by volunteers, so I guess that is true. The actual proposals ("What we propose") also are odd to me: 1. The Boost Foundation represents boost? According to whom? I don't think there even is an agreement between the Boost Developer Community and the Boost Foundation. If anything the Boost foundation is supposed to be the benefactor of Boost, not it's owner. 2. How do the two points build community? Policing discussion usually has the opposite effect. 3. We are migrating to CMake? I thought this additional support. Why does a proposal include "consider"? That is just vague and non-binding. 4. That just sounds like a power-grab. This is because defining the roles will mean it will be the Boost Foundation defining the roles and creating the succession plans. It will be the Boost Foundation deciding who needs to be replaced because they don't perform well. It will be the Boost Foundation administering the "keys to the kingdom", e.g. the boostorg github organization, which they currently don't. We as developers might be able to nominate someone, but we sure won't elect them. That will be the Boost Foundation's doing. It would mainly give the Boost Foundation all the control over Boost, including the ability kick library authors they don't like from their own repositories. Additionally, there is no agreement between the developers and the foundation here. It's vague and gives the Boost Foundation carte blanche to treat boost authors like employees. # What is your expectation of it's implementation? A) If the agreement with the C++ Alliance is signed we have a legal document with obligation. I don't think a non-profit would mess around with that, so I believe it would be implemented. B) Based on my reading of the proposal of the Boost Foundation I think they'll implement their ideas and will try to control boost developers and their speech. If it's implemented the way it reads to me I might not be a boost author anymore. On the other hand, there is no legal obligation by the boost foundation here. They could just raise funds and invest in the Beman Project instead. # What is your expecation regarding the usefulness of the proposed changes? A) This proposal would at the very, very least keep the lights on. It would most likely end the stagnation of boost on the infrastructure side (e.g. new website). The C++ Alliance has proven their willingness & ability to do that with drone. It is also quite possible that new steering committee will actually be able to steer boost, if it is made up by developers. This would overcome issues in boost, because instead of commanding from on-high to migrate to CMake, the developers would first put in the work to build consensus (by building the thing) before announcing move. It looks to me like this has succeeded with CMake thanks to Peter and is in the works for a modularization by Rene. I see no downside here if the agreement is signed & honored. I have no reason to doubt that this will be the case. B) All this proposal will do is give the Boost Foundation dictatorial control over Boost. Since they've been busy blocking any non-library effort (like the new website) unless they can take credit, I am sure it would be the certain death of boost. I vote to ACCEPT the proposal of the C++ Alliance.

Disclaimer: C++ Alliance employee, Boost developer, and Boost user Although the review is "confined to management and control of those Boost assets listed," both proposals went beyond only justifying why they are fit to control these assets: the C++ Alliance proposal includes a committee for the assets instead of controlling them directly, and the Boost Foundation proposes new rules it would be able to enforce. For instance, I can't interpret what it means to say that a "strong and enforceable code of conduct" or that "governance remains with the Boost Foundation" is only regarding a "role in the administration of those assets." For this reason, I'm looking over the full content of both proposals, and I would like to ask that my comments be discarded if these other parts of the proposals are decided to be non-binding. I also previously sent an email expressing my belief that both institutions could work together. Unfortunately, this ship has sailed. However, on the bright side, both sides of the discussion identify and attempt to solve the same challenge: there's a "new way" of doing things, and Boost needs to decide what to do about it. This "new way" of doing things includes technical and community issues: build systems, the WG21 process, package distribution, the very existence of GitHub, codes of conduct, inclusivity rules, and even how to handle social media. Regarding this premise behind the proposals, I think people tend to overestimate the usefulness of these "new ways" of doing things and underestimate how effective the community has been in valuing the pros of these new strategies and adopting their best portions: - As a user, I often start a new project and notice I need Boost for some task. It may take some time to set it up, depending on the environment, but that takes half an hour for a project I might be working on for years. After setting it up, I'm mostly happy for a long time, which impacts me the most. I would rely on Boost even if floppy disks were the only way to consume it. Before someone distorts what I'm saying, I'm not saying we shouldn't worry about how Boost is distributed. But we can't forget that high-quality libraries are more important than anything else. - There's a lot of work going on in Boost that needs more praise, and some discussions seem to imply that this work doesn't even exist. All these libraries, even the ones where the authors are gone, keep working on newer and newer compilers, and many people seem to take this for granted. Much work has been done on CMake, modular library consumption, and cyclic dependencies. Recent work has also been done on B2 support for modular libraries. Package managers already rely on this work to provide Boost libraries individually. There's also been a lot of work on and discussion about C++ modules. The Boost developers are directly behind all of that. - The idea that package management in C++ is a solved problem must be more accurate. I do use these tools, but they're still far from perfect. There's a lot of work to be done. - As people seem to imply, the WG21 issue goes way beyond the motivation behind the proposals or the difficulty behind the Boost review process. Not all Boost libraries are intended to go through WG21. Not all WG21 proposals would make good Boost libraries (like begin/end iterators for std::optional). And for the Boost libraries that could make suitable standard components, even if no political motivations existed, we would still have a technical problem: the things missing from C++ in 2024 are much more complex than they used to be. It's much easier to propose a standard API for `std::min_element` that satisfies enough people to justify standardization than a standard API for `std::json`. And there are valid reasons why this bar should be higher for C++ than Python or Javascript. These more and more complex demands will also make Boost proposals and reviews more complicated over time. It's also an excellent opportunity for Boost to provide practical things that exist more conveniently in other languages but are too complex to be standardized in C++. As I'm focused on development, I did not participate in the C++ Alliance proposal and read it for the first time from the link Glen shared on this list. From this proposal, I was left with the impression the premise is that while we could adopt the good parts of the "new ways" of doing things, what we currently have is also very valuable. My shared concerns about this proposal were mostly about Boost relying too much on a single entity for financial support and some unnecessarily controversial behavior by the C++ Alliance. All of these issues were better explained during the review, and the most critical ones were resolved by the new committee formed by the developers. So, in a way, the C++ Alliance proposal is the one that attempts to contemplate a way for Boost to move on without the C++ Alliance. - I understand the concern about depending on a single institution for financial support. However, going from one to zero institutions providing financial support is unreasonable. The solution is to find more sources of financial support. The new committee and the developers should constantly work on that. - From the narrative I got in previous emails, I had concerns about the alternative boost.io domain being unnecessarily confrontational. Fortunately, Joaquin's explanation clarified that the domain went live after the community gave the green light for a new website, before the Foundation announced it would cut ties with the C++ Alliance, and the home page does say "Proposed for Boost.org." - Another concern raised about the C++ Alliance having "too much money" is that it invested a lot in things the community didn't care as much about. Regarding the logo, that's not a considerable problem besides the money used. However, in the case of the website, I agree it's worth studying how it can be maintained in an emergency. This would be a problem for any website. The new website uses Django, which is comparatively simple to maintain. - The legal language in the proposal might be complex for some people, including me. The document could have had some more explanation in simple terms. Fortunately, Andrzej and Andrey asked good questions here, and the answers helped me understand the new structure. I assume more questions of this kind will come up over time to help clarify this content even more. But at least from what I understood, the C++ Alliance includes a path where the decisions are made by developers directly or through the committee instead of attempting to aggregate power in a single institution. - The C++ Alliance is the only institution that worries and does something significant about the most thankless and tedious tasks we need, such as CI, hosting, and mailing lists. Only yesterday, I learned from the C++ Alliance about Hyperkitty ( https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/), which is one possible solution to reduce the distance between people not used to mailing lists without creating a bad experience for or imposing something on the existing community. The idea that we can ignore these thankless issues and figure them out later is unconvincing to me because if these things were easy to figure out, they would be already figured out by now. On the other hand, when confronted with the problem posed by the "new ways" of doing things, the proposal by the Boost Foundation starts from the premise that Boost is wrong about most things and that the only way to save it is to change it radically. Thus, their proposal includes new rules they would have the authority to enforce to save Boost. Zach Laine's email helped me understand the history behind this disconnect, as it was counterintuitive to me that the existing institution would be making the proposal that asks for more changes and rules. My conclusion was that the premise behind this proposal is that (i) the "new ways" of doing things are the right way, and the community should be guided to abandon what we have much faster in favor of these new approaches; (ii) the foundation should be granted authority to punish or kick out members of the community so they learn to behave in front of people who do things the new ways; and (iii) if the community refuses to accept any of that, there's nothing worth saving here, and as there's no way to force them to work on something they don't want, we need to invest in an alternative project with other people to do things the right way. The specific technical problems I see with the proposal are: - The foundation's investment in the Beman Project and the claims I saw of it being "what Boost was and no longer is" make no sense to me. To be clear, I would have nothing against a Beman Project Foundation doing any of that. - As mentioned above, Boost CMake support already exists, and some people are discussing it as if there's been almost no work. Our only issue is a conflict between the directory layouts for CMake and B2. We distribute a "monolithic" directory layout, B2 supports the "monolithic" and "modular" layouts, and CMake only supports the "modular" structure. With enough communication, many alternatives exist to solve this conflict and allow CMakeLists.txt in the official distribution. We're not as far as some criticism seems to imply. - Regarding Discord, the community has repeatedly declined to move from the Mailing List. I'm not a big fan of Mailing Lists, but I see no point in insisting on that. - About a document describing rules for behavior, we already have one: https://www.boost.org/community/policy.html. As some people have mentioned, it's correct that the content of the rules of behavior and inclusivity is irrelevant unless it's enforceable. However, this makes matters even worse. The content of these rules is also not very relevant when they are enforceable because then discussing the power structure to interpret and enforce them is way more important than the content. Even the proposal provides evidence of that: it highlights enforceability but doesn't describe the proposed content of the rules. By not providing details on how it would be enforced, I can only assume the same group of people would be doing the interpretation, the prosecution, the judgments, and applying penalties. Luckily, I'm not the only one to identify this problem. - Unless "libraries being self-contained" means using the "modular" layout I described above, the proposal to impose that libraries be self-contained is impractical in some cases and bad practice in others. It's even a contradiction if your value proposal is, "Please use my library as a dependency: the biggest selling point is it doesn't have dependencies because everyone is replicating the content of these other libraries we used to depend on." It's also impractical because you can't force people to voluntarily work on something they don't want for their libraries. On the other hand, if "being self-contained" only means the modular layout mentioned above, this is not a massive problem for Boost. It's something the community has already been working on for a long time. - As many have mentioned, lack of responsiveness, even during this review, also concerns me. I've seen arguments that that's not a problem because they're busy volunteers or because you could go there and participate directly in some form if you are worried about it. I've heard similar arguments multiple times in other contexts and find them equally unconvincing. At the risk of overexplaining here, the whole point of any representative body is to act on behalf of different people in a way that emulates how you would decide otherwise. They are usually created because getting everyone involved all the time is not considered a good idea in the context. If they can't act on your behalf in this way for any reason - be it because they don't have enough time or even disagree with the opinions they're supposed to represent - their existence is unjustified. I vote ACCEPT for the C++Alliance's Fiscal Sponsorship Proposal I hope any tension will decrease after this review, and we can enjoy the new website. Em ter., 3 de set. de 2024 às 12:35, Glen Fernandes via Boost-announce < boost-announce@lists.boost.org> escreveu:

Dear Boost community,

The Boost Asset Stewardship Review begins today, 3rd September and ends on 22nd September.

For reference, the review schedule is: https://www.boost.org/community/review_schedule.html

The submission which initiated the review is the following proposal from the C++ Alliance: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf

It proposes a Fiscal Sponsorship which:

1) is a legal agreement where the C++ Alliance holds assets on behalf of the Boost project. It proposes a newly formed (steering) committee that would be composed of Boost developer community members that would determine how the assets are used.

2) donates the assets that it funds to the Boost project (domains, hosting, etc.)

The "Boost developer community" here refers to: - Boost library authors - Boost library contributors - Boost release managers

For a high level overview of these terms (which I needed) see the following email with definitions: https://lists.boost.org/Archives/boost/2024/09/257579.php

The Boost Foundation asks the Boost developer community to consider the following alternative:

https://docs.google.com/document/d/1XFt7Bh71e4_uE0iK4jifhR__P0iG5_c1cDfBsMjr...

The Boost Foundation proposal presents a path forward where it continues to be the steward the assets in question, but offers a change in how these are managed.

The assets here refer to the following: - The boost.org domain - Website hosting - Mailing lists - Downloads storage and CDN - Drone CI

Currently, the Boost Foundation owns and pays for the following: - Website hosting - Mailing lists

The C++ Alliance pays and manages for the following: - The Drone CI - The CDN for the downloads - The download archive - Technical assistance and support for the Boost release process - Backup domain names (in case boost.org expires) - Hosting and downloads for the new website prototype (boost.io)

The boost.org domain is absent from both lists above: The Boost Foundation technically does not own it yet. The domain was owned by Beman and he had the credentials. The Boost Foundation is working with Beman's widow and the Dawes Estate to transfer ownership to it.

For reference, see Kristen's email: https://lists.boost.org/Archives/boost/2024/08/257563.php

Note that the content of the current boost.org site and the new boost.io website is still the province of the Boost developer community.

To be clear, the review is not about deciding governance over Boost C++ library development. That remains in the hands of the Boost developer community.

Please send all reviews to the Boost developer mailing list. If you do not want to create an account, you can email me at glenfe -at- boost.org with your review and I will post it to the list for you.

Include "Asset Stewardship Review" or "Asset Stewardship" in your email subject.

In your review do disclose any affiliation to either the C++ Alliance or Boost Foundation groups. Please state any connection you have to Boost (developer, user, package manager etc.)

Thank you, Glen _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

-- Alan Freitas https://alandefreitas.github.io/alandefreitas/ https://github.com/alandefreitas

Le mardi 03 septembre 2024 à 11:35 -0400, Glen Fernandes via Boost a écrit :

It proposes a Fiscal Sponsorship which:

1) is a legal agreement where the C++ Alliance holds assets on behalf of the Boost project. It proposes a newly formed (steering) committee that would be composed of Boost developer community members that would determine how the assets are used.

I'm sorry that such questions come late in the review, and they may well be just coming from my lacking knowledge of how things work in the US, but i have a really hard time understanding the parties involved. It's pretty clear for the C++ Alliance. It's much less clear to me for the "boost project" side. The document states : « This Agreement is made by and between The C++ Alliance ("Alliance") and Ion Gaztañaga Muñoa, Joaquín M López Muñoz, and René Ferdinand Rivera Morell (the "Current Committee") on behalf of the project known as Boost (the "Project") ». My understanding is that it is an agreement between a non-profit and three physical persons. So, my guess is that part of the outcome of this review is acknowledging that these three persons (or five, as some have suggested to add a few names) can act on behalf of the boost community. Is that correct? The document the talks about the steering committee, gives some minimal rules about how it works, but that does not makes it a “legal” entity. In France, we have a concept of « association de fait », but they have very limited rights. Wikipedia translates that as “Unincorporated association”. Is that the kind of association that will be the steering committee ? One last thing, the document is very us law oriented, whereas Boost is an international organization. I'm concerned, for example, by clause 8.a.1: the Successor is another nonprofit corporation which is tax-exempt under IRC Section 501(c) (3) My understanding is that this clauses actually prevent any non-us organization to be the Successor. While it may not be the intent, this is not something i would take lightly. Or is it just bad understanding of us laws from my side? Sorry for asking these question so late in the review process, and thanks for any answers you could provide. Regards, Julien