Re: [Boost-announce] Boost Asset Stewardship Review begins today (3rd Sept)

From: Alan de Freitas (alandefreitas_at_[hidden])
Date: 2024-09-14 00:43:18

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/[e-mail]/),
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_at_[hidden]> 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_c1cDfBsMjrljU/
>
> 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>