Hi Artyom, You raise fair points and valid concerns — Boost is a powerful project, but precisely because of its scope and depth, it comes with real challenges when used in long-term or production-critical environments. If I were to summarize your points: - There's a lack of API/ABI stability - No clear LTS versions - Frequent internal changes that make maintenance difficult over time If those things don’t exist yet, it’s likely not just oversight. As others have mentioned, Boost is largely maintained by volunteers — people working on their own time, without funding. Given the scale and decentralized nature of Boost, aligning on policies, release cycles, and long-term guarantees is no small task — and I have no doubt that for decades now maintainers have been doing their best with the time and resources at their disposal. Still, that doesn’t mean we can’t work toward a better state. There’s likely room for a more pragmatic middle ground. One practical idea would be to identify and curate a stable subset of Boost — libraries that are very mature, very stable, and widely adopted in industry. Just having a baseline like this could help reduce friction for teams that need reliability across long software lifecycles. Of course, a counterpoint is that Boost’s peer-review process is already strict and demanding, and formalizing a “stable subset” might be seen as creating second-class citizens within the ecosystem. But it could just remain informal/informative. So even without changing Boost’s internal policies, I believe the first step should be at least to gather real-world data on API stability and user experience — that would at least help guide future decisions based on actual usage and pain points. It could be valuable to start collecting both maintainer and user feedback: - Which Boost components are most painful to maintain versus to use ? - Which APIs feel solid versus which evolve often? - What would help users most versus what would deserve maintainers most — LTS branches, versioning guidelines, better deprecation signals? - Interestingly I have not seen a document or page summarizing the volatily/stability/dynamics of Boost libraries. Surely the middle ground lies in understanding these challenges better. Even just identifying where users struggle the most could help cut through the fog and prevent maintainers from solving problems that may not actually exist. That kind of clarity could lead to a community-driven effort — or at the very least, offer maintainers better insight into the real needs of the broader user base. As a broader takeaway, it’s also important to acknowledge that what you’re asking for likely requires a communication-first approach. The community has already made significant strides here — from improving the website and documentation to making key information more accessible. These (huge) efforts deserve recognition, and they’re laying the groundwork for the kind of dialogue we need: between maintainers, between users, and especially between maintainers and users <3 Happy to help with sketching ideas, collecting feedback, or processing user input across platforms if that’s useful. That of course includes your input, Artyom :) Best wishes, Arno