The Beman Project: Analysis
Great Founder Theory in C++
Abstract
The Beman Project, launched in 2024 under David Sankel’s leadership, aims to create a pipeline for C++ standard library proposals through reference implementations. This paper analyzes the project through Samo Burja’s Great Founder Theory, examining its structural design and likely outcomes. The project’s defining architecture—wherein libraries are retired upon standardization—limits its potential to create lasting ecosystem value. Boost asked “what libraries do users need?” The Beman Project asks “what papers need implementations?” These produce different kinds of institutions.
Introduction
In May 2024, at the C++Now conference, the Boost Foundation launched the Beman Project, describing it as:
“A new initiative separate from Boost that gets back to its original purpose of improvements to the standard library.”
Named in memory of Beman Dawes—co-founder of Boost, longtime Library Working Group chair, and one of the most influential figures in C++ history—the project aims to provide reference implementations of libraries proposed for ISO standardization.
This paper applies Great Founder Theory to analyze the project’s design and prospects.
The Beman Project: Structure and Goals
Stated Mission
From the project’s documentation:
“The Beman Project’s mission is to support the efficient design and adoption of the highest quality C++ standard libraries through implementation experience, user feedback, and technical expertise.”
The tagline—”Tomorrow’s C++ Standard Libraries Today”—emphasizes its role as a staging ground for standardization.
Library Lifecycle
Beman libraries progress through four stages:
Under Development — Not ready for production use
Production Ready, Unstable API — Suitable for production but API may change
Production Ready, Stable API — Fully production-ready
Retired — No longer maintained; triggered when the proposal is rejected, superseded, or integrated into the standard
Technical Infrastructure
The project mandates:
CMake-based builds (required)
Apache License 2.0 with LLVM Exceptions (recommended)
GitHub-based development with CI/CD
Specific naming conventions (
beman.<short_name>)
Current Libraries (2025)
beman.exemplar— Template/Demo (P0898R3)beman.optional— Stage 2 (P2988, P3168)beman.execution— Stage 1 (P2300)beman.inplace_vector— Stage 1beman.net— Stage 1beman.scope— Stage 1beman.task— Stage 1 (P3552)beman.dump— Retired
The Retirement Architecture
The Beman Project’s defining feature—retiring libraries upon standardization—represents a deliberate design choice. The logic is coherent: once a library enters the standard, the reference implementation has served its purpose.
Consider the lifecycle:
A WG21 paper author implements a library
The library develops through Beman’s stages
WG21 accepts the proposal
The Beman library is retired
At the moment of success, maintenance ends. Third parties who adopted the library during development face a choice: migrate to the standard library version (requiring compiler upgrades) or fork the unmaintained implementation. Organizations evaluating dependencies typically prefer libraries with long-term maintenance commitments.
The Boost Comparison
Boost took a different approach. When boost::shared_ptr was standardized as std::shared_ptr in C++11:
The Boost version continued to exist and be maintained
Users who couldn’t upgrade compilers could continue using Boost
The Boost version could evolve independently
This created sustainability. The contrast crystallizes into a question of purpose:
Boost asked: “What libraries do users need?”
Beman asks: “What papers need implementations?”
Implications
The retirement model means:
Limited production adoption: Organizations hesitate to depend on libraries with planned obsolescence
Reduced feedback quality: Without broad production use, user feedback remains narrow
No accumulation: Unlike Boost’s 160+ libraries creating network effects, Beman libraries are isolated implementations
Great Founder Theory Analysis
The Framework
Samo Burja’s Great Founder Theory offers tools for analyzing institutions:
Functional institutions are rare: Most organizations imitate functional ones without replicating what makes them work
Great founders create social technologies: Innovations in coordination that enable sustained collaboration
The succession problem: When founders depart, their innovations often fade
Beman Dawes’ Contributions
Beman Dawes created several social technologies that made Boost functional:
The Formal Review — Peer-review process for library acceptance
The Boost Software License — Unified licensing eliminating compatibility conflicts
The Federated Author Model — Individual ownership with collective distribution
Implementation-First Development — Build it, use it, then propose standardization
These weren’t just processes—they were innovations that enabled collaboration at scale.
Two Different Visions
The projects differ in orientation:
Audience: Boost serves users; Beman serves WG21
Success: Boost measures adoption; Beman measures standardization
Lifespan: Boost libraries are permanent; Beman libraries retire upon success
Flow: Boost is bottom-up (author-driven); Beman is top-down (paper-driven)
The Beman Project isn’t trying to be Boost—it’s explicitly “separate from Boost.” But naming it after Beman Dawes creates an expectation of continuity with his approach. Dawes built a permanent collection with BSL licensing and bottom-up proposals. The Beman Project builds temporary implementations with Apache licensing for paper implementations.
Leadership and WG21 Context
The Beman Project emerges from overlapping leadership positions:
David Sankel — Boost Foundation Director (former Exec. Director), Reflection TS Editor, Beman founder and lead
Jeff Garland — Boost Foundation Exec. Director, WG21 Vice-Convener (2026+) and LWG Assistant Chair, Beman co-founder
Inbal Levi — Boost Foundation Director and GSoC Chair, LEWG Chair
Zach Laine — Boost Foundation Treasurer and Director, SG9 Co-Chair
This overlap explains the project’s orientation: the Beman Project is effectively an extension of WG21’s institutional infrastructure, designed to serve committee needs.
David Sankel’s approach favors structured, top-down coordination. This was visible in the 2017 CMake discussion, where he proposed a migration path decided by the Steering Committee, and in the Beman Project’s launch at C++Now without extensive mailing list deliberation. The Beman Project reflects its leadership’s strengths—standardization expertise, committee relationships—rather than attempting to replicate Boost’s emergent dynamics.
The Ecosystem Gap
C++ faces structural challenges outside the standard’s scope:
ABI fragmentation: GCC, Clang, and MSVC produce incompatible binaries
Package management: No unified system (vcpkg, Conan, Spack compete)
Build system complexity: CMake dominates but integration remains difficult
Dependency reluctance: Developers avoid dependencies due to integration pain
Adding more libraries to the standard doesn’t address these issues.
The Beman Project assumes WG21 proposals need implementation experience before standardization. This is reasonable—implementation experience helps. But it may not be the binding constraint. std::regex had extensive implementation experience (from Boost) and remains notoriously slow. Committee dynamics, ABI constraints, and design-by-committee effects often matter more than whether a reference implementation exists.
Meanwhile, the problems that are binding constraints receive less attention. The Beman Project invests resources in an area that was already relatively functional while areas that desperately need work remain unaddressed.
20-Year Projection
The Beman Project will help several proposals advance through WG21 over the next decade; reference implementations will provide useful feedback during LEWG review; some libraries will achieve standardization and be retired as designed. But without permanent libraries or production users, the project cannot accumulate institutional momentum—each success triggers retirement rather than growth. Volunteer participation may decline as contributors see their work archived rather than maintained. The project will likely continue in reduced form, serving WG21’s needs for reference implementations: a useful but narrow tool rather than a major ecosystem institution. Boost, by contrast, accumulates value through its permanent collection; network effects create ecosystem lock-in; the BSL remains the gold standard for permissive licensing. With Alliance funding providing stability through leadership transitions, Boost will likely still exist in 20 years, still serving users, still maintaining libraries.
Conclusion
The Beman Project’s architectural choice—retiring libraries upon standardization—determines what it can become. It produces temporary implementations rather than permanent infrastructure. It cannot accumulate the way Boost accumulated.
Boost created permanent value for users.
Beman creates temporary value for WG21.
Boost is infrastructure. The Beman Project is a pipeline.
Meanwhile, C++’s binding constraints—package management, ABI stability, build system fragmentation—remain unaddressed by either project.
References
Primary Sources
The Beman Project. “Hello from The Beman Project.”
https://bemanproject.org/
Boost Foundation Board Minutes, 2024
Sankel, David. “The Beman Project: Bringing C++ Standard Libraries to the Next Level.” CppCon 2024
Burja, Samo. Great Founder Theory. 2020 Manuscript
Secondary Sources
Falco, Vinnie. “The Future of Boost.” C++ Alliance Blog, May 2023
“The Ecosystem Gap: What the C++ Standard Cannot Specify.” 2025
Revision History
2025-12-24 — Revised for concision: converted tables to lists, removed redundant disclaimers, consolidated 20-year projection