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