This section contains answers to the common questions that new contributors to Boost often have.
-
Do Boost libraries typically come from gauging outside interest, or perhaps more from developers following their own interests?
Most Boost Libraries originate from individual developers, or small teams, following their own interests, rather than from organized external demand. Typically, self-motivated developers identify a gap in the C++ ecosystem or have a strong interest in a particular domain. To be clear, Boost is not driven by corporate feature requests, community polling or public wishlists, nor top-down direction (though The C++ Alliance might sponsor, or partially sponsor, work it deems of specific value, such as it did with Boost.Json). The community acts as a gatekeeper to ensure quality, generality, and long-term usefulness, rather than as a source for library concepts.
-
When considering developing a library for Boost, what is the right balance between ambitious functionality and limited functionality?
The keys to a successful development of a new library are to identify core functionality and start simple. Prioritize functionality that provides significant value to developers and aligns with Boost’s goals of promoting high-quality, reusable libraries. Avoid adding unnecessary features that may increase complexity without adding much value. It’s often beneficial to start with a simpler implementation that addresses a specific problem or use case effectively. A library with a narrow focus and a clear, intuitive API is more likely to be accepted by the Boost community than one that attempts to solve too many problems at once or introduces unnecessary complexity.
In addition to this, consider future extensibility, performance, portability, current trends, and always remember you can seek community advice and feedback through the Boost mailing lists.
-
Am I right in thinking that Boost libraries are typically low-level and very specific, rather than higher-level and for tackling large scale issues such as generative AI, a modern game engine, or quantum computing, to name a few examples?
Yes, Boost libraries have traditionally excelled in areas such as high-performance computing, cross-platform, embedded systems, and networking. Taking your example of generative AI, many Boost libraries could be used as components of a new AI model - such as parsing, networking, serialization, errors and exception handling, math and statistics, randomness, and so on. A new quality generative AI model is a considerable undertaking, and Boost libraries could do a lot of the grunt work and leave a development team with the most creative aspects. Simulating quantum computing, or creating a modern game engine, gets a similar answer, a development team could focus on the interactive UI, with Boost libraries handling a myriad of administrative and operational tasks.
A key aspect of a successful Boost library is focus: what is the problem that the library in question is the solution for?
-
If there is social media discussion on new libraries, typically what does the discussion entail?
The new libraries most requested tend to be more like updates to existing libraries. There’s a common desire for more comprehensive asynchronous programming support, often for higher-level abstractions or more extensive async features. Another example is more programming options, say for an enhanced version of Boost.ProgramOptions, or for libraries supporting earlier or later C++ standards, such as requests to support pre-C++17 standards.
-
Where can I read the current version of the Boost Software License?
Here: The Boost Software License.
-
How should Boost programmers apply the license to source and header files?
Add a multi-line comment based on the following template, substituting appropriate text for the name and date on the top line:
cpp
// Copyright (c) 2004-2006 Joe Coder
// Distributed under the Boost Software License, Version 1.0.
// (See accompanying file LICENSE_1_0.txt or copy at
// https://www.boost.org/LICENSE_1_0.txt)
Notes
-
Leave an empty line before and after the above comment block.
-
It is fine if the copyright and license messages are not on different lines; in no case should there be other intervening text.
-
Do not include "All rights reserved" anywhere.
-
Other ways of licensing source files have been considered, but some of them turned out to unintentionally nullify legal elements of the license. Having fixed language for referring to the license helps corporate legal departments evaluate the Boost distribution.
-
Creativity in license reference language is strongly discouraged, but judicious changes in the use of whitespace are fine.
-
How should the license be applied to documentation files rather than source files?
Similarly to the way it is applied to source files: the user should see the very same text indicated in the template above, with the only difference that your local copy of LICENSE_1_0.txt should also be linked to.
-
How should Boost programmers maintain the copyright messages?
Copyright is only claimed for changes meeting a certain threshold of originality. Therefore, the copyright message only covers expressions of creativity. It is up to authors of changes to add themselves to the copyright message if they so decide. Typically, a new claimant is added when someone takes over maintenance of a library or a new version of an existing library is developed. In principle, do not remove previous copyright claims - just add new claims and/or claimants.
-
How is the Boost Software License (BSL) different from the GNU General Public License (GPL)?
The GNU General Public License is longer, and may be harder to understand. The Boost license permits the creation of derivative works for any use with no legal requirement to release your source code. Other differences include BSL not requiring reproduction of copyright messages for object code redistribution, and the fact that BSL is not "viral": if you distribute your own code along with some Boost code, the BSL applies only to the Boost code (and modified versions thereof); you are free to license your own code under any terms you like.
-
Why the phrase "machine-executable object code generated by a source language processor"?
To distinguish cases where we do not require reproduction of the copyrights and license (such as object libraries, shared libraries, and final program executables), from cases where reproduction is still required (such as distribution of self-extracting archives of source code or precompiled header files). More detailed wording was rejected as not being legally necessary, and reducing readability.
-
Why is the "disclaimer" paragraph of the license entirely in uppercase?
Capitalization of these particular provisions is a US legal mandate for consumer protection.
-
Does the copyright and license cover interfaces too?
The conceptual interface to a library is not covered. The particular representation expressed in the header is covered, as is the documentation, examples, test programs, and all the other material that goes with the library. A different implementation is free to use the same logical interface, however. Interface issues have been fought out in court several times; refer to a lawyer if this is likely to be an issue.
