September 2024 - Boost - lists.boost.org

Boost Asset Stewardship Review from Andrey
by Andrey Semashev 12 Sep '24

12 Sep '24

[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-advan…) 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. :)

4 6

A history of the Boost Foundation
by Zach Laine 11 Sep '24

11 Sep '24

Dave Abrahams and Beman Dawes put up the initial money for BoostCon (which has since been renamed to C++Now) in 2007 (or maybe 2006?). This was something of a risk, since it was not certain how many people would show up. It turns out that the conference covered those costs, but they were still personally responsible for the conference if they wanted to put it on again the next year, or the year after. Beman had the idea that there should be an independent legal entity for this, rather than two individual people. I forget the exact chronology, but pretty early on in the conference history, we ended up with The Boost Steering Committee, under the Software Freedom Conservancy (SFC). That is, we called it "The Boost Steering Committee", but there was no such legal entity. The legal entity that represented the BoostCon conference and Boost in general was SFC. In terms of legal entities, "The Boost Project", or "The Boost Steering Committee" was just a single division within SFC. This is something they reminded us of from time to time. At the time, Boost had no real expenses. The "wowbagger" server that we use to host the (now, legacy) website, and on which the releases are built, was hosted at Indiana University. The downloads of the build Boost releases were hosted at Sourceforge (I think; anyway, wherever it was, it was free). They later moved to other places, ending up finally at JFrog. They're no longer hosted for free -- see below. BoostCon made more money than it spent for a lot of years. It accumulated some reserves, and people would sometimes ruminate on what we might spend all that sweet, sweet cash on. No large expenditures were ever taken on though. The SFC started very small. We were project #3 I think (maybe #2? something like that). Over a few years, it took on more and more projects, until Boost was one of 20 or 25 SFC projects (again, I don't remember the exact numbers). SFC had a small staff then, and probably still does. As they grew, it became increasingly difficult to get anything done. They were overworked and understaffed, so this is not some failure on the part of the SFC so much as a logistical inevitability. One problem we had was getting them to pay vendors for services used by the conference. IOW, we would use some service, the vendor would send us a bill, and then we would send SFC like a thousand emails trying to get them to pay the bill. It was a nightmare to deal with. Jon Kalb, who was the conference chair at the time, asked the Steering Committee if we'd be open to breaking free of SFC, and forming our own non-profit organization -- a separate legal entity. Everyone agreed, Jon did a bunch of research and paperwork (thanks again, Jon!) and we formed a new 501(c)(3) US corporation called The Boost Foundation. This is why the Steering-Committee-under-SFC became the Boost Foundation Board. This is also why the name changed -- we needed a new name for the new legal entity. There was no secret agenda; there was no smoke-filled room. There was, however, pragmatism. Sometime around then -- once more, I don't remember the exact timeline -- we started losing all our free stuff. Someone at Indiana University realized that randos (that's us, Boost) were running a whole server in their lab, and asked us to remove it. So then we had to pay for hosting wowbagger. Some time later, the download hosts stopped giving away bandwidth for free as well. No problem, right? The conference makes money, Boost now needs money, so let's use the conference money for the Boost expenses that now have to be paid. (Note that this is something the SC/Board took on as it came up; it was not part of the original mission of the SC/Board, because there were no significant Boost infrastructure expenses previously.) The problem is that the conference makes less and less every year, due to a combination of changes in the way the venue charges (it all went up a lot), inflation, the expenses from the covid-cancelled year, etc. During all this, we kept things running as best we could. Eventually, the downloads became too expensive, and the C++ Alliance offered to pay for those. So now they do. The Foundation only pays for hosting wowbagger right now. Hopefully that sets the stage. To me, the important take-away is that the Foundation has tried to "keep the lights on" as I like to say, without bothering anyone on the list about it. The Board does more than just Boost infrastructure stuff, such as organizing the C++Now conference, and more recently, paying the hosting fees for the Beman Discourse server. Sorry this is so long. :) I may have some of these facts slightly wrong. Like, did BoostCon actually start in 2006? I couldn't figure out definitively which year it was, even though I was there. But I'm much more certain about the major events, and the reasons for things. I also left out most of the non-asset-stewardship aspects of the Steering Committee/Foundation, since they are mostly not germane to the current review. I nevertheless refer to one such aspect below. In light of the history above, here are some points I'd like to make regarding things I've seen said on this list about the Foundation: 1) The Board does not impose its will on the developers on this list. It does sometimes make recommendations or official "calls" of some kind, like saying we should use CMake. It doesn't actually have the ability, as the Boost Foundation Board, to enact such changes. This is not a matter of restraint. It simply can't make concrete changes; only the Boost developers can. Also, there never has been, and doesn't appear to me that there ever will be, any appetite for meddling in Boost development, or forcing developers to do things. 2) The Board is self-selected, in the sense that the Board nominates and votes on Board seats. Multiple Boost authors are on the Board: Peter Dimov, Glen Fernades, Jeff Garland, and me. There are others who are only there for the conference business. There are others, who joined more recently, interested only in Beman. 3) I've read on this list about the desire to "get back" to the Boost Steering Committee way of doing things. This does not make sense. There is no difference between the Boost Steering Committee and the Boost Foundation, except for the name. Sure, there is a change in membership over time. That would have happened with or without the name change. Perhaps this is a desire not to have the current Board membership? If so, please get involved. Asking a volunteer project to do things differently, without volunteering to help yourself, doesn't usually work out. Which brings me to: 4) The Board is a volunteer project, like Boost is. As such, people work mostly on what they care about, and don't really do much for things they don't care about. So when I read, "The Board is not communicating enough," I think there are a couple of things to consider. 4a) Do we expect volunteers to do the stuff they want to work on, and then communicate that they did that to someone else that was not working on that same thing? Do we do that with our Boost libraries? I might communicate changes, including bug fixes, in release notes. I do this because it affects others. But if I make a non-functional change, who do I tell, and why? Note that, when there has been a loss of service, someone has mentioned it on the list right away, as far as I know. Do we also want people to mention when the Board took some action that kept a loss of service from happening? Moreover, I'm not sure what transparency is lacking, given that: 4b) The board publishes minutes of every meeting, and you can come to the meetings if you're interested. Except for occasionally needing to handle a sensitive topic that we do not minute due to its sensitivity, these are not closed meetings. For example, our latest Board member was asked to join the Board because he kept showing up to these open meetings out of his own interest, and would take on tasks from time to time. As you all know, this is how pretty much all open source/volunteer projects work. In short, I think if a Boost user wants to know the details of how Boost works, they subscribe to the Boost mailing list. If a Boost developer wants to know the details of how the Boost Foundation works, they read the minutes and/or come to the meetings. Zach

5 6

Re: [boost] A history of the Boost Foundation
by Zach Laine 11 Sep '24

11 Sep '24

On Wed, Sep 11, 2024 at 2:41 PM Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > >> > > 1) The Board does not impose its will on the developers on this list. >> > > It does sometimes make recommendations or official "calls" of some >> > > kind, like saying we should use CMake >> > > >> > >> > So the email about cutting ties with the C++ Alliance, which started all >> > this, was just non-binding minority report? >> >> I don't get it. Isn't this the thing the developers are voting on >> right now? How is the Board imposing a change on the developers? > > > The original email had no proposal of a vote. Nor did it sound like a recommendation. Right. But again, where was the impact on the Boost developers? I, as a Boost developer was not expected to, nor asked to, do anything differently from what I had done before. This vote was all about the Board not wanting to deal with the Alliance. We think that there would be an adverse impact on the Bosot developers, and think, "screw the developers!" If we expected our decision to adversely affect Boost development, we would have made a different one. Zach

2 2

Boost Asset Stewardship Review from Matt
by Matt Borland 11 Sep '24

11 Sep '24

DISCLAIMER: I am a C++Alliance Employee Prior to my employment by the C++Alliance I had been a contributor to Boost for a few years primarily in the Math domain. I enjoyed working with everyone, so when an opportunity to join the C++Alliance came around I took it. I agree with the foundation that the core of Boost is volunteers, but by adding a number of part time and full time employees we are able to handle much larger projects and sustained maintenance that may just be otherwise unfeasible. I don't think, for example, GCC would be better off without RedHat employees working on it because many people depend on it just like many people depend on Boost. I like that the C++Alliance is heavily invested in the future of Boost and it's infrastructure. Drone is fast and has a diversity of architectures that aren't available in Github Actions. We've been adding CUDA support to Boost.Math and a testing environment for that was happily provided since there is a heavy demand signal from our users. The new website is a pretty clear improvement over the current one. We also have Sam Darwin who is already helping the distribution of Boost happen behind the scenes. I see no reason to not want to work with an organization that literally puts their money where their mouth is. The fiscal sponsorship model and the new steering committee are the right choice for the future. The fiscal sponsorship model is not new and worked for Boost in the past. The three (possibly five) members of the initial steering committee all have public and sustained interactions with the Boost community. I trust they have the best interests of the project in mind since they have skin in the game. I would like to echo what Chris said in his review. Tensions have obviously been high over the past weeks and months between some rather large personalities. Once this referendum is complete I hope that we can have a peaceful transfer of power and return to a more cordial environment with a focus on how we can make Boost better moving forward. Bottom Line: I vote ACCEPT for the C++Alliance's Fiscal Sponsorship Proposal Matt

2 1

[Asset Stewardship] A request for clarification
by Andrzej Krzemienski 10 Sep '24

10 Sep '24

Hi All, I have a couple of questions to the C++ Alliance representatives regarding the Fiscal Sponsorship Proposal. First, the proposal is very clear and informative. Thank you for this. I still have some questions, though. In Appendix 1: Paragraph 2.c says, "all community programs [...] shall be the ultimate responsibility of Alliance. What is meant by "community programs" here? Paragraph 3 says "should Alliance be required to pay any taxes [...]". What taxes do you mean here? Can you give an example? Paragraph 3 also uses the term, "Project agrees". Is this a mistake, or intentional? I understand that the Current Committee can agree to something. Or that the Steering Committee can agree to something. But how can the Project agree? Additional two questions. 1. When I am a maintainer of a library, what does it make me in the light of this agreement? Am I part of the Project? Or a donor to the Project? Or something else? 2. I have a problem internalizing who decides and signs-off on the complement of the Current Committee. Don't get me wrong. I personally support the proposed complement (including the proposed amendments); I just wonder how it works logically/legally. The Current Committee cannot appoint itself. The Alliance cannot arbitrarily say "you, you, and you". Is this Boost Asset Stewardship Review a vehicle for the legitimization of the Current Committee? Paragraph 8.d says, "If no Successor is found, Alliance may dispose of the Project assets and liabilities in any manner consistent with applicable tax and charitable trust laws." This sounds very harsh to me. If the Project faces the necessity to find another sponsor, and this fails, is the Alliance allowed to offer the domain name for sale, get rid of the mailing list archives, or offer the logo to someone else? Appendix 3 -- I do not see how it illustrates the boost.org Domain Registration Expiration Appendix 6 -- It is very nice promotional material. Thank you for doing this. But the term "the Official C++ Language Slack Workspace" draws my attention, and I have always wanted to ask this: what makes this slack workspace "official"? Neither Boost nor the C++ Alliance represents C++ or could make decisions or blessings in the name of C++. So, is it not a stretch? Regards, &rzej;

3 5

Boost Asset Stewardship Review - Some questions received
by Glen Fernandes 10 Sep '24

10 Sep '24

The following questions were sent to me about the assets that the C++ Alliance already manages. My replies are included: 1. What are these alternate domains, and how do they differ from boost.io ? These are domains that the C++ Alliance provided for us when we had that issue where boost.org was down for a long period of time. At the time I wasn't sure we would even get boost.org back or what the timeline for recovery would be. I thought that we should provide a backup domain that users can be directed to until the issue is resolved. The C++ Alliance offered to help and registered boostlibraries.org and boostcpp.org that point to our website hosting. boost.io is the domain for people to preview the new website that the C++ Alliance built, developed by Fastly with content contributions from Boost users and developers. 2. Why do we need to pay to support downloads if the hosting is free? The storage costs are minimal but the bandwidth is not. At one point Boost downloads approached 60TB per month and Bintray couldn't afford to support us for free. JFrog generously offered to take over. Recently, our downloads started approaching almost 200TB per month, and now even JFrog couldn't afford to keep hosting us for free. They suggested we use a CDN to reduce traffic costs. I reached out to multiple providers to get a good deal. The best rate was from Fastly but this was also too expensive. The C++ Alliance offered to handle these costs and we subscribed to Fastly. Sam Darwin administers our Fastly account. For the list discussion, you can start at: https://lists.boost.org/Archives/boost/2024/01/255654.php Glen

4 4

Re: [boost] Replacing the ML with a forum
by Andrzej Krzemienski 09 Sep '24

09 Sep '24

śr., 26 kwi 2023 o 16:08 Vinnie Falco via Boost <boost(a)lists.boost.org> napisał(a): > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > Every message comes as a separate email to me. > > Are you using a threaded e-mail reader? Gmail groups all the emails from the topic as an email thread. > If so, do you care if > discussions are changed to be flat (like Discourse)? What does "flat" mean here? I am not familiar with Discourse. Could we get a sample or example? Regards, &rzej; What is important > to you (besides that you can continue to use your email client)? > > Thanks > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

5 7

Boost Asset Stewardship Review from Jakob
by Jakob Lövhall 09 Sep '24

09 Sep '24

I’m not affiliated with either the C++ Alliance or the Boost Foundation. I’m merely a boost user and sends occasional patches as contribution. The regulatory parts of the proposals are naturally US specific, and I want to make it clear that I do not understand the nuances of those parts. This is my short review. Boost Foundation: The bullet points and values stated in the proposal from the Boost Foundation seems strange to me and does not align with what I have been able to discern from public discourse. I haven't seen the transparency that’s being discussed. Engagement to provide said transparency seems lacking from the Boost Foundation. The emphasis on inclusivity over merit feels like a pathway to decline, as it explicitly excludes other groups beyond the intended inclusivity targets. This seems harmful to Boost and its community and should be avoided. The Boost foundation highlights code of conduct (and policing the discussion) as important going forward. I think it can be damaging, and should thus be avoided. Additionally, the Boost Foundation has not adequately addressed the infrastructure needs of Boost. In contrast, the C++ Alliance has stepped in to handle these concerns. C++ Alliance: Vinnie and others from the C++ Alliance have been actively engaging with the community on Slack and the mailing list—my two main points of contact. This provides transparency, builds relationships, and fosters discussions around technical issues, all of which are beneficial. The C++ Alliance has provided much-needed infrastructure assistance, particularly in cases where the Boost Foundation has failed to address long-standing issues (e.g., wowbagger). They support the maintenance (and at times creation) of libraries which I find useful. They promote on twitter, which I like, I've found good tools and libraries from twitter before and I expect others to also do so. having Boost on twitter therefore helps reaching those who might not have thought about boost when thinking about how to solve their current (C++) problems. The C++ Alliance focuses on merit over identity, which I believe is the right approach. Conclusion: I vote to ACCEPT C++ alliance proposal.

2 1

Regression Test Crashing
by Tom Kent 09 Sep '24

09 Sep '24

All- I've been pretty busy lately so just noticed this, but as of August 18 *all* the regression runs have broken during execution. The tail of the results log shows: - cxx11_char16_t : yes [47] - cxx11_char32_t : yes [47] - windows-sdk-supports-bcrypt : no [14] - windows-sdk-supports-bcrypt : no [51] error: Unable to find file or target named error: '/mnt/fs1/teeks99-06/run/boost_root/libs/charconv/build//stage' error: referred to from project at error: '../tools/check_build/test' Similar on windows: - cxx11_char32_t : yes [62] - windows-sdk-supports-bcrypt : yes [21] error: Unable to find file or target named error: '/C:/teeks99-09/run/boost_root/libs/charconv/build//stage' error: referred to from project at error: '../tools/check_build/test' Tom

4 8

Boost Asset Stewardship Review from Frank Wiles
by Glen Fernandes 08 Sep '24

08 Sep '24

Frank contributed the following review below, sent to me directly. > Vote: Transfer Boost Assets to the C++ Alliance > > Association with library: Occasional user. Long time OSS contributor > in other areas. Was paid to help C++ Alliance build the new boost.io > > Rationale: > > While my association with Boost is not large, I have seen first hand > the care the C++ Alliance has taken to both "do the right thing" and > drive for consensus with the Boost community. > > As someone who has been deeply involved in other software nonprofits > (Django Software Foundation directly, Python Software Foundation > tangentially) this proposal is certainly well thought out and > detailed. Most importantly it covers "end state" cases in the event > the Steering Council or C++ Alliance want to change or end the > relationship in the coming years. > > It seems clear to me that the C++ Alliance is driving the majority of > air in terms of breathing new life into Boost and the assets can > safely be within their control, if for no other reason than to reduce > friction in continuing to push things forward. > > -- > Frank Wiles > President/Founder of REVSYS > www.revsys.com > @fwiles Frank, thank you again for the review. Glen

1 0