Charter: Mission, Scope, Values, and Principles

The purpose of having a charter for your open source project is to help people understand the mission, scope, and values / principles, and having this documented early can help avoid issues and misunderstandings later. The overall cloud native ecosystem is complex with many projects containing overlapping functionality. A project charter[1] can help end users understand how your project fits into the overall ecosystem and what functionality it does / does not offer as compared to the many alternatives. The project charter can take many different forms, and it’s often not called a charter at all, but instead takes the form of a mission statement, scope, values / principles, and similar concepts often found within the governance documents or project READMEs.

Mission Statement

For CNCF projects, we recommend including a mission statement that helps people understand the purpose, advantages, and key features of your project in your README.md file. In most projects, the first few sentences of the README contain the mission statement, although it may not be labeled as such. It should provide a clear and concise description of the project containing the purpose (what the project does), advantages (why it’s important / useful), and key features of the project.

Examples:

• Harbor is an open source trusted cloud native registry project that stores, signs, and scans content. Harbor extends the open source Docker Distribution by adding the functionalities usually required by users such as security, identity and management. Having a registry closer to the build and run environment can improve the image transfer efficiency. Harbor supports replication of images between registries, and also offers advanced security features such as user management, access control and activity auditing.
• Linkerd is an ultralight, security-first service mesh for Kubernetes. Linkerd adds critical security, observability, and reliability features to your Kubernetes stack with no code change required.

Scope

By clearly documenting what is in and out of scope for your project, you can avoid misunderstandings about your project. The scope documentation helps end users understand what they can expect your project to do or not do. It also helps contributors understand which types of new features are likely to be accepted into the project and which ones are out of scope. The scope should be included in your README file or linked from the README as a separate file if it is too long to include.

Examples:

• containerd will distribute images, but not build them ( containerd scope doc).
• Kubernetes operates at the container level, not the hardware level, so it manages your containers, but will not maintain your hardware ( Kubernetes scope doc).
• The scope of CRI-O is tied to the scope of the CRI ( CRI-O scope doc).

Values / Principles

It is also good practice to include a statement of values or principles within your governance documentation. While the scope includes information about what your project does, your values / principles define how you work. They often include statements about openness, transparency, inclusion, being welcoming and respectful, and much more.

Examples:

• Kubernetes principles and community values
• CoreDNS principles
• Vitess guiding principles
• Cilium community values

These are all living documents that should be expected to change over time as the project evolves. For sandbox projects, this might be a simple one or two sentence statement about what the project does, and by the time a project has graduated, they would probably have a more detailed mission statement, scope, and values / principles. All of this documentation should be consistent with the mission and values in the CNCF Charter.

[1]: Note: SIGs also have charters that serve a similar function and often contain mission statements, scope, etc.