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. We find that the project’s architecture—wherein libraries are retired upon standardization—limits its potential to create lasting ecosystem value. We contrast this with Boost’s implementation-first model and suggest that C++’s actual needs lie elsewhere: in package management, ABI stability, and build system standardization. The Beman Project represents a good-faith effort by capable people, but its design constrains what it can accomplish.
Table of Contents
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 Samo Burja’s Great Founder Theory framework to analyze the project’s design and prospects. Our goal is not to question the motives of those involved—the Beman Project’s contributors are accomplished professionals acting in good faith—but to examine whether the project’s structure can deliver lasting value to the C++ ecosystem.
The analysis suggests that while the Beman Project may help individual proposals advance through WG21, its architectural choices limit its potential as an enduring institution.
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 Maturity Model
Beman libraries progress through four stages:
A library reaches Stage 4 (Retired) when the proposal is rejected, superseded, or—notably—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)
The Retirement Architecture
Design Choice and Consequences
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.
However, this choice has significant consequences for the project’s role in the ecosystem.
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, the implementation is marked complete and 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.
This creates a practical barrier to adoption. 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: users could depend on Boost regardless of their compiler or standard version.
The contrast crystallizes into a question of purpose:
Boost asked: “What libraries do users need?”
Beman asks: “What papers need implementations?”
Neither question is wrong—they serve different goals. But they produce different kinds of institutions.
Implications for Adoption
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 narrower than it might be
No accumulation: Unlike Boost, where 160+ libraries create network effects, Beman libraries are isolated implementations
This isn’t a criticism of the people involved—it’s an observation about structural constraints.
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 innovations that made Boost functional:
These weren’t just processes—they were social technologies that enabled collaboration at scale.
Two Different Visions
The Beman Project and Boost represent different visions of library development:
The Beman Project isn’t trying to be Boost—it’s explicitly positioned as “separate from Boost.” But naming it after Beman Dawes creates an expectation of continuity with his approach.
Dawes built a permanent collection serving users with BSL licensing and bottom-up proposals. The Beman Project builds temporary implementations with Apache licensing for paper implementations. These are legitimately different visions—but the naming may obscure rather than clarify that difference.
Leadership and WG21 Context
Personnel Overlap
The Beman Project emerges from a network of interconnected leadership positions:
This overlap isn’t inherently problematic—these are competent individuals with deep standardization experience. But it does explain the project’s orientation: the Beman Project is effectively an extension of WG21’s institutional infrastructure, designed to serve committee needs.
Governance Patterns
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.
This style has merits: clear direction, defined outcomes, professional execution. But it contrasts with Boost’s historically organic, author-driven culture. The Beman Project reflects its leadership’s strengths—standardization expertise, committee relationships—rather than attempting to replicate Boost’s emergent dynamics.
The Ecosystem Gap
What the Standard Cannot Specify
As analyzed in the ecosystem gap paper, 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.
Addressing the Right Problems
The Beman Project assumes: “WG21 proposals need implementation experience before standardization.”
This is reasonable—implementation experience does help. 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—package management, ABI, build systems—receive less attention. The Beman Project invests resources in an area that was already relatively functional (standardization has been producing libraries for decades) while areas that desperately need work remain unaddressed.
This isn’t a failure of the Beman Project specifically—it’s a broader ecosystem prioritization question. But it does suggest the project’s impact will be narrower than the C++ community’s actual needs.
20-Year Projections
The Beman Project: 2025-2045
Likely trajectory: The 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.
Structural limitation: 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.
Probable outcome: The project continues in reduced form, serving WG21’s needs for reference implementations. It becomes a useful but narrow tool rather than a major ecosystem institution.
Boost Under Alliance Stewardship: 2025-2045
Likely trajectory: Infrastructure modernization continues. The library collection evolves—some libraries sunset, new ones enter. The Formal Review process maintains quality standards. Alliance funding provides stability through leadership transitions.
Structural advantage: Boost’s permanent collection accumulates value. Network effects (libraries depending on each other) create ecosystem lock-in. The BSL remains the gold standard for permissive licensing in C++.
Probable outcome: Boost remains essential C++ infrastructure, adapted to language evolution (modules, improved compile times). Core libraries continue serving millions of users.
Summary
Conclusion
The Beman Project represents a good-faith effort by capable people to improve C++ standardization. Its goals are coherent and its execution is professional.
However, its architectural choice—retiring libraries upon standardization—constrains what it can become. The project serves WG21 rather than users. 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.
This isn’t wrong—it’s a different purpose. But it means the Beman Project will likely remain a narrow tool serving committee needs rather than growing into a major ecosystem institution.
Meanwhile, C++’s actual challenges—package management, ABI stability, build system fragmentation—remain largely unaddressed by either project. The Beman Project doesn’t solve them; Boost doesn’t either (though Alliance-funded work on build integration helps).
In 20 years, Boost will likely still exist, still serve users, still maintain libraries. The Beman Project will likely continue in some form, helping proposals through WG21. Both outcomes are fine—but they’re different in kind. Boost is infrastructure. The Beman Project is a pipeline.
The question for the C++ community isn’t which project is “better”—it’s whether we’re investing enough in the ecosystem problems that neither project addresses.
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’