Boost Asset Stewardship Review from Andrey

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-09-11 17:07:44

[Warning! Long post ahead!]

Hi,

This is my review of Boost asset stewardship proposals from The Boost
Foundation (the current governing organization) and The C++ Alliance.

I. Are you knowledgeable about the problem domain?
==================================================

Not particularly. Although I can probably consider myself an old-timer
(I think, I joined the mailing list back in 2007; at least my archive
dates back that far), I have never been privy to Boost infrastructure
and management details. The only information I know is what was
published on the mailing list (ML). I have also never managed a company
or organization outside Boost. I am neither a lawyer nor financist, and
English is not my native language, so I may misunderstand some of the
information given in the proposals. Sorry if that's the case.

However, as a Boost library maintainer and user, I am interested in the
Boost project's bright future. Specifically, the future where I'd be
willing to continue using and contributing to Boost. While this may
sound selfish, my hope is that my contributions will also make Boost
more useful to others. So, my review will be written mostly from a
maintainer's and user's perspective rather than someone knowledgeable in
the problem domain, which is primarily asset management and legal
relations between organizations.

I am not affiliated with The C++ Alliance or The Boost Foundation.

II. The problem statement
=========================

In order to evaluate the proposals, I will first state the problem, as I
understand it. Then, I will see how each of the proposals addresses it.
I will separate the problem description into three aspects:

1. Boost popularity decline.

As stated in both proposal documents, Boost popularity has declined in
recent years, based on metrics such as the number of posts in the ML,
the number of submitted libraries or the number of git commits per year.
The C++ Alliance proposal provides the relevant data in Appendix 2.

My personal perspective is that *volunteer participation* in Boost is
indeed reducing. Here, by volunteers I mean contributors that are not
staffed by The C++ Alliance and contribute their work independently. It
appears like Boost "went out of fashion" and going though a Boost review
is too difficult and time consuming for newcomers, and so they are
picking easier alternatives to publish their code and ideas and gain
recognition. In doing so, new developers seem to be willing to trade the
quality of their solutions for popularity and quick gains.

I'm not entirely convinced that this lack of participation is caused by
how modern our website looks or how often we post news items on social
media. While these things do matter, I suspect the fundamental issue is
that newer developers simply don't want to bother with the review
process and responsibly maintaining code afterwards for various reasons.
I find this tendency extremely sad and worrying, even more so since it
is not unique to Boost.

However, I do not think we can say that Boost *usage* is declining. From
the data presented in The C++ Alliance proposal, it looks like the
number of Boost downloads is growing, so much so we had to contract a
CDN provider to serve them, as well as introduce GitHub downloads.
Athough I imagine large portion of these downloads are automated (e.g.
CI jobs), even that interpretation speaks in favor of a growing user
base (more CI jobs probably means more projects are using Boost). I
suppose, it should not be surprising that there are more users than
contributors, but I still think it is worth pointing out that Boost
popularity is not declining, as it may appear from some online forum
comments.

2. Boost asset management.

There were several instances of poor management of Boost assets, such as:

- The boost.org domain, which was nearly lost to an auction.
- The website. The current website is mostly unmaintained, and there is
no (public) plan of modernizing it. The new proposed website is rejected
by The Boost Foundation and remains "unofficial" at boost.io.
- Social media accounts. The official @Boost_Libraries account on X is
dormant, and the access to it is restricted from members of The C++
Alliance who have volunteered to maintain its activity. Which resulted
in creation of a separate, "unofficial" @BoostLibraries account.
- The wowbagger server that is running the current website and mailing
lists is outdated and have seen hardware failures that resulted in data
loss (as noted in The C++ Alliance proposal). The software stack on the
server is also outdated and cannot be easily updated.
- The Boost logo, for which, apparently, The Boost Foundation doesn't
hold the appropriate license.

The duplicate website and X account are especially bad for users, as it
causes confusion as to which one is genuine and the true source of
information. They are also very similarly named, so much so that one
might question their legitimacy.

I'd like to point out that the issues with Boost downloads, when we
exceeded the free downloads quota, were largely solved with help of The
C++ Alliance and The Boost Foundation (specifically, I believe, Sam
Darwin and Glen Fernandes). This is an example when the two
organizations (or perhaps, individuals thereof) have collaborated to
solve the immediate problem. Many thanks to everyone involved.

3. Lack of communication with asset management body.

I think, many of Boost community were unaware of the asset management
issues listed above until recent discussions on the ML. I personally did
not know about the issues with boost.org, data loss on wowbagger and
licensing issues for the logo until recently. I believe, some of these
issues could have been solved sooner if they were communicated on the ML
by The Boost Foundation.

Furthermore, even after the issues have become known, there were,
depending on the specific asset, little to no communication from The
Boost Foundation as to (a) whether the problem is real and (b) what is
the proposed plan on addressing it. Basically, The Boost Foundation took
a reactive stance in regards to The C++ Alliance actions that it (the
Foundation) perceived as hostile.

III. Evaluation of The Boost Foundation proposal
================================================

My overall impression of the proposal is that it lacks substance and in
some ways is not aligned with Boost traditions. Following is my analysis
of how the proposal tackles the stated problem.

1. Boost popularity decline.

A significant portion of the proposal is titled "Our Community Values".
I'd like to note that this seems to implicate that these values are
those of the Boost project community rather than those of The Boost
Foundation. This is further reinforced by the contents of the "What we
propose" section, which stem from these stated values. I do not believe
this implication is correct. In fact, I do not see these values listed
anywhere on the www.boost.org website or the "Proposal for a C++ Library
Repository Web Site" (https://www.boost.org/users/proposal.pdf).

While some of the values listed in the proposal are aligned with the
spirit of the Boost project, others are not. In particular, the
"Inclusivity" section discusses representation of women in The C++
Alliance staff and the proposed Steering Committee. This is entirely
irrelevant for the purpose of Boost asset management and looks like a
cheap stab at the opponent. The document then goes on to propose to
"make an active effort to get those historically underrepresented to
participate". I think, this is an entirely wrong approach to the problem.

Boost has never been about representation of women, or any other social
category for that matter. The relevant portions of our guidelines are this:

  A guiding principal is to encourage wide participation and
  interaction. Get people involved, in newsgroups, mailing lists,
  as peer reviewers, library contributors and maintainers, and as
  moderators and webmasters. And, of course, as library users.

(https://www.boost.org/users/proposal.pdf)

  Boost libraries are intended to be widely useful, and usable across
  a broad spectrum of applications. The Boost license encourages the use
  of Boost libraries for all users with minimal restrictions.

  [...]

  Boost welcomes and thrives on participation from a variety of
  individuals and organizations.

(https://www.boost.org/)

Notice that nowhere in these lines specific social groups are mentioned.
I'd like to think this is intentional. The only criteria mentioned is
talented people willing to contribute their time, ideas, code and effort
to various areas of Boost, an open and widely useful collection of C++
libraries. Martians included. As soon as you substitute this criteria of
technical merit with inclusivity/representation agenda, you are taking
away from the technical quality of the community and bringing in
unhealthy atmosphere of inequality. Ultimately, this harms the project
as a whole. I find this unacceptable.

Another related suggestion made in the proposal is introduction and
enforcement of "a strong code of conduct". Also, "make an active effort
to improve behavior on the mailing list". The proposal does not go into
details as to what the "strong code of conduct" might look like, or in
what way the behavior on the mailing list needs to be improved, but
given the inclusivity agenda I have to make some uncomfortable
assumptions. Specifically, that the suggested code of conduct is
intended to promote the agenda and could potentially be used to
prosecute those who disagree.

I know I have commented on this topic earlier, but I feel compelled to
make this part of my review. I find this sort of code of conduct, as
well as using it as leverage on people unacceptable. I do not want to
see Boost descending into curating people's opinions (let alone their
behavior outside Boost), segregation, preferentialism and political
infights. I think, our current discussion policy strikes a good balance
between defining what's considered unacceptable behavior and leaving
enough freedom to keep the discussions vibrant and productive. I don't
remember a case when we needed something more strict, and I don't
remember us needing to enforce it onto someone either.

Lastly in this problem category is the suggestion to "consider adopting
a modern communication platform, such as discourse". There was a
discussion on this topic on the ML (unfortunately, threading was broken
at the time, but you can search by "Replacing the ML with a forum" in
the title), which showed a strong preference for ML in the community. I
do not think switching to a web forum solution, especially one that does
not support threading, would be in the best interest of the community.
It may attract more new users, but it will also push away active
developers. New users are not necessarily going to replace the
maintainers who are going to leave. Personally, I'm not seeing myself
switching to a web forum.

If the suggestion is not to switch but to bring up a forum *in addition*
to the ML, this is also not a good solution, IMO. If the two platforms
are independent from each other, this will result in community
fragmentation, which I would like to avoid. In particular, this would
make review discussions problematic, assuming the review would happen
both on forum and ML.

I'm not against a forum interface per se, but I think it should
integrate with the ML, so that people using both interfaces are able to
communicate with each other transparently. Which is something similar to
what The C++ Alliance is working on.

2. Boost asset management.

I feel that this aspect of the stated problem is not addressed by the
proposal nearly at all. Which is disappointing, since I was hoping that
this aspect would receive the most attention of The Boost Foundation
given the recent communications on the ML and direct requests from the
community.

The proposal mostly states that The Boost Foundation retains ownership
of the assets and undergoes internal organizational changes so that each
asset is associated with a given member of the Foundation. While
personal responsibility and staff rotation are good, this doesn't really
address the issues at hand. For example, what is the proposed resolution
with the website? The logo? The wowbagger server? And so on. These
questions remain unanswered.

3. Lack of communication with asset management body.

Out of the three problem aspects, I got the most positive impression on
this one from the proposal. I do like the idea of introducing key
officers on the ML, as well as open board meetings. On the latter, I
would like to amend so that online attendance should be possible, as not
everyone lives near the location of the board headquarter, or wherever
the meeting takes place.

I would also like to see periodic reports on the ML (e.g. once a
quarter) on what was done in the given period, what are the current
problems, who is working on them, what was done and what is the plan
going forward. I would like to see more active responses from The Boost
Foundation on direct requests from the community. Perhaps, set up a
public issue tracker so that people are able to report problems and
track their progress. This might be as simple as a GitHub project with
an issue tracker and a task list
(https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists).

4. Other thoughts.

The proposal suggests "Complete the CMake migration". While I'm not
opposed to continued work on CMake support, I do not think it is The
Boost Foundation's role to declare tasks like this. It is a decision
made by the Boost community, and the work is done by library maintainers.

Same for "Consider putting the monolithic distribution in maintenance
mode and require new libraries to be self contained". This is not a
decision to be made by The Boost Foundation; it must be discussed on the
ML first. To this end, I do not think requiring all new libraries to be
self-contained (that is, not have any dependencies) is realistic or a
worthy goal to pursuit anyway.

IV. Evaluation of The C++ Alliance proposal
===========================================

My overall impression is that The C++ Alliance proposal is more
substantial and comprehensive, which I like.

1. Boost popularity decline.

The proposal describes the work that The C++ Alliance has been doing to
improve participation in the project. I'm assuming, the proposal implies
that the work will continue if the proposal is accepted. In particular,
these items were mentioned:

- The new, "refreshed" website
- A more active X account, with a new image art design
- A C++ Slack workspace, which is used for Boost-related chat-style
communications
- Updated mailman+hyperkitty ML backend in development which will offer
a web forum-like interface for the ML
- Marketing materials and merchandise distributed on CppCon

Those are all very welcome endeavors, especially those which improve
accessibility and communication between people. I think, improved
communication is a key element of improving public image of Boost and
bringing in new contributors - perhaps, more important than the
refreshed "looks".

As I said in the problem statement section, I think the most deterring
factor for potential library contributors is the necessity to undergo a
Boost review and then maintain the submitted library. Some developers
who target the C++ standard perceive Boost as an unnecessary effort that
can be avoided. I'm not sure the above measures will help overcome this
perception, but at least they should make Boost more accessible to
contributors offering help in other ways, e.g. by providing user
feedback and patches. I think, the only party who can improve the
situation with the straight-to-standard libraries is WG21, which is out
of our hands. What Boost can do is maintain the high quality bar, even
if it means less volunteers than we'd like.

Besides attracting more volunteers, The C++ Alliance is sponsoring
development and employ engineers working on Boost. On one hand, this
makes things done and provides another steady flow of contributions,
especially in the unpopular areas, like documentation updates. On the
other hand, Boost is increasingly becoming controlled by The C++
Alliance, where the majority of roles are fulfilled by the Alliance's
employees. There is a saying in my country that can be translated as
"the one who dines a girl also dances her", which basically means the
one who does the work should also reap the benefits from it. I suppose,
it's fitting, but I would still prefer Boost to remain an independent
project. This is actually my biggest concern with The C++ Alliance
proposal - it further increases control of the Alliance over Boost.

2. Boost asset management.

The core of the proposal is to transfer ownership of the Boost assets to
The C++ Alliance, to be managed on behalf of the newly created Steering
Committee, which is supposed to be formed from Boost community members.
In the past, The C++ Alliance have demonstrated that they are willing
and able to solve issues with Boost infrastructure and assets.
Specifically, to address the aging website, a new one was (and still is)
developed, to fix archive downloads a CDN provider was contracted and so
on. And although I have reservations about the new logo usage terms and
looks, it also exists as a solution to the licensing issues with the old
logo. So clearly, this demonstrates that The C++ Alliance is capable of
maintaining Boost assets in good condition.

However, The C++ Alliance is still an external entity, which is funded
by a single individual, Vinnie Falco. This poses risks associated with
possible funding issues and changing directional vision for The C++
Alliance and by extension, Boost. The first risk may be mitigated by
finding other sources of income, such as donations and merchandise
distribution, which, I believe, was the source of funding until now,
with The Boost Foundation. The second risk is supposed to be mitigated
by introduction of the new Steering Committee, which should represent
the Boost project community and define "the technical, artistic and
philanthropic direction" of the project.

This last part I would like to investigate further. In the Fiscal
Sponsorship Agreement (FSA) draft in Appendix 1 of the proposal, two
Committees are mentioned. The Current Committee, as I understand it, is
sort of a bootstrap for the Steering Committee, and its members are
listed in the FSA. I am not sure why the Current Committee is needed,
and why is it not possible to form the Steering Committee from the start
and only reference it in the FSA. Maybe there's some legal reason to it
that I'm not aware of, but it looks like a superfluous entity to me.

Another point is that in the list of members of the Current Committee,
two of the three members are also members of The C++ Alliance. The FSA
does not outline the decision making process in the Current Committee,
but strangely does so for the Steering Committee:

  All decisions of the Steering Committee shall be made by
  simple majority.

This raises two issues. First, if the Current Committee's decision
making process is the same then The C++ Alliance has the majority vote
in the Committee. I'm not questioning the integrity of the proposed
members of the Current Committee, I have nothing but respect for each of
the individuals, but I would still prefer if The C++ Alliance didn't
have the deciding majority on the Committee. Someone on the ML proposed
to include Glen Fernandes and Peter Dimov in the Current Committee, and
I support this nomination. Furthermore, I would like the similar problem
with the Steering Committee to be mitigated as well. One option is to
amend the mechanism for picking members to restrict The C++ Alliance
presence in the Committee to less than majority of members. Another
option might be to involve the community in the member election, e.g. by
holding a vote for candidates. In any case, the goal is to ensure that
the Steering Committee represents the Boost project community rather
than The C++ Alliance.

The second issue is that I find it surprising that FSA is defining the
decision making process in the Steering Committee in the first place. It
would seem to me that the Steering Committee should have its own bylaws
and should decide on how it operates internally, and that has nothing to
do with FSA. As long as the Steering Committee's decisions go in line
with the FSA, it should not matter how these decisions are made.

I'd like to note that I have no preference for the Steering Committee's
decision making process; my issue is not with the "by simple majority"
part. Although there should be a tie breaker, if the number of members
is even.

Another thing that bothers me is that The C++ Alliance reserves the
right to appoint members of the Steering Committee to bring its size up
to three members. I realize that this is supposed to be an emergency
plan of sorts, but it seems wrong that The C++ Alliance is making the
pick. It would seem, the self-preservation plan should be in the
Steering Committee's bylaws, and The C++ Alliance should not be acting
in its place.

Lastly on this topic, the last part of this sentence seems controversial:

  Authority to manage the technical, artistic and philanthropic
  direction of the Project and the program activities of the Project
  is delegated to the Steering Committee as defined in §6, subject
  at all times to the direction and control of Alliance’s Board of
  Directors.

It might be my poor understanding of the legal wording, but it looks
like this suggests that the Steering Committee is operating under
control of The C++ Alliance's Board, which contradicts with the first
part of the sentence. Either the Committee decides on the Project's
direction, or it is controlled by the Alliance and then it is the
Alliance who actually decides on the Project direction. My preference
would be the former, in which case this sentence should probably be amended.

I would like to comment on the section 8 of the FSA, "Termination". I'm
not familiar with the US laws, but do the timeouts for searching for a
Successor allow for registering a new 501(c)(3) entity for the purpose
of passing the assets to it? The way the section 8.d "Termination
Without a Successor" is phrased implies that the assets could
potentially be destroyed or otherwise made permanently unavailable to
the Project. I'm wondering if there is a better solution, like creating
a new non-profit for the purpose of passing it the assets. I admit I'm
completely clueless in this domain, I'm just looking if the Termination
terms could be improved for Boost. Especially, in the case if The C++
Alliance is no longer able to fulfill its sponsorship.

3. Lack of communication with asset management body.

The C++ Alliance members already post periodic reports about the
Alliance's activity, and I hope this initiative will continue if the
proposal is accepted. Alliance's members are also active on the ML,
which is very welcome. So, in the communication department The C++
Alliance has a good track record already.

One instance where the communication did fail was the attempt to
purchase the boost.org domain from the Dawes estate. I feel, this matter
could have been handled better. At the very least, the community could
have been made aware of the situation with the domain name and the
planned resolution. I can understand how this buyout attempt could be
interpreted as a hostile action by The Boost Foundation, and The C++
Alliance (and Vinnie Falco in particular) should have known this would
be the outcome. If the proposal is accepted, I would like to ask the
Alliance to be transparent about their planned and ongoing activities
wrt. Boost assets to avoid situations like this in the future. Doing
things like buying the domain name behind everyone's back is not
acceptable. In fact, this should be straight prohibited by the terms of
FSA, as the Alliance is supposed to act on behalf of the Steering
Committee when it comes to Boost assets.

Lastly, the suggestion I made in The Boost Foundation proposal review
regarding GitHub tasks and issue tracker might be relevant here as well.

V. Conclusion
=============

Given that The Boost Foundation proposal lacks substance on the asset
management part, leaving many questions unanswered, and is taking what I
consider a completely unacceptable direction on the community engagement
front, I vote to REJECT The Boost Foundation proposal. I understand
there likely won't be a second round of review, but if there was, I
would have liked to see a more constructive proposal that is more
focused on the problems at hand and proposed concrete solutions for
them. Where the opponent offers a solution, you should be offering yours
instead of stabbing the opponent.

I find The C++ Alliance proposal closer to what I would like to see in
Boost. On The C++ Alliance proposal I vote ACCEPT WITH CONDITIONS with a
single condition being to ensure that the newly created Steering
Committee is able to make decisions and operate independently from any
possible leverage from The C++ Alliance, in the interests of the Boost
project. The specific concerns I have on this front are described in the
proposal review.

I'd like to thank The Boost Foundation and The C++ Alliance for putting
forth their proposals. I'm sure they put a lot of work in it. And I'd
like to thank Glen Fernandes for managing this review, which surely is a
difficult and responsible task.

And if you read this far, thanks for your time and patience. :)