Log In
Log In

Boost C++ Libraries and Fiscal Sponsorship

The Boost C++ Libraries has thrived with the support of volunteer work and support for more than 25 years. That support includes the variety of assets Boost relies on to deliver high quality libraries. Things like website, email lists, testing machines, and library contributions. Recently disagreements about how those assets get managed arose between the C++ Alliance and the Boost Foundation. To resolve the situation the Boost community, and in agreement with the C++ Alliance and the Boost Foundation, held a Formal Review in early September 2024 (https://lists.boost.org/Archives/boost/2024/09/257584.php)

The Boost community uses Formal Reviews as a method to reach informed decisions. Although mainly used for evaluating proposed libraries, it provides the community with an opportunity to collect rationale (positive or negative) to move forward on directions to take (https://www.boost.org/community/reviews.html)

The result of this particular Formal Review (https://lists.boost.org/Archives/boost/2024/09/257941.php) was to affirmatively take two steps:

  1. Choosing the C++ Alliance as the designated Fiscal Sponsor of Boost assets.
  2. Formation of a “Fiscal Sponsorship Committee” (FSC) to direct the use of those assets on behalf of the Boost community.

The reviews posted during this review were well thought out and invaluable in reaching consensus in this direction. The initial members of the FSC, as indicated in the proposal reviewed, are now:

  • Ion Gaztañaga
  • Joaquín M López Muñoz
  • René Ferdinand Rivera Morell

The FSC is moving forward with implementing the community direction. And we will post additional updates in the future.

Thank you,
Boost C++ Libraries Fiscal Sponsorship Committee

Next Post

  • Fuzz testing
    Blog
    Fuzz testing is described as a technique that injects random data into software functions to expose crashes, memory leaks, and undefined behavior, especially in code handling untrusted input. A fuzzing engine repeatedly runs the target code with varied inputs, instrumenting it to collect coverage information that guides the generation of further samples, most of which are malformed. Crashes and sanitizer violations are monitored, making the approach valuable for libraries that parse or decode network data, such as Boost.Json, Boost.URL, and Boost.Mysql. Unit tests are still required, as they verify expected results, while fuzzing complements them by focusing on stability rather than correctness. LibFuzzer is recommended as the default engine because it is coverage‑guided, evolutionary, and bundled with clang, requiring only the addition of ‑fsanitize=fuzzer flags during compilation.