CHAOSS Project Charter

The Linux Foundation

CHAOSS – Community Health Analytics Open Source Software

Project Charter (the “Charter”)

Effective: Sept 1, 2017

Last Updated: January 14, 2026

This Charter sets forth the responsibilities and procedures for technical contribution to, and oversight of, the CHAOSS – Community Health Analytics Open Source Software Project (the “Project”) within The Linux Foundation. Contributors to the Project must comply with the terms of the Charter as well as any applicable policies of The Linux Foundation.

1. The Project Mission

The mission of the Project is to:

  1. produce integrated, open source software for analyzing software development, and definition of standards and models used in that software in specific use cases;

  2. establish implementation-agnostic metrics for measuring community activity, contributions, and health; and

  3. optionally produce standardized metric exchange formats, detailed use cases, models, or recommendations to analyze specific issues in the industry/OSS world.

2. Governance Board

  1. The Governance Board (the “GB”) shall be responsible for overall oversight of the Project and coordination of the efforts of any Technical Committees and Working Groups.

  2. GB voting members will be elected from the contributing community to serve a 2-year term. The election procedures and methodology are documented in https://github.com/chaoss/community/elections.

  3. CHAOSS software projects are defined in the Software Subprojects section of the CHAOSS Governance document (https://chaoss.community/governance/). Each CHAOSS software project will have a dedicated seat on the GB. Each software subproject must define an election process to select their representative. The representative must meet the eligibility criteria to run in the election. That representative serves a 2 year term when this election process needs to be repeated.

  4. The GB will encourage transparency (e.g. publish public minutes). Committee and Working Group meetings will be open to the public, and can be conducted electronically, via teleconference, or in person.

  5. The GB has the authority to create Committees that may focus on code or non-code efforts to advance the Mission (such as standards, specifications, and/or architecture).

  6. Working Groups are established and maintained by Project contributors to advance Project work. Working Groups focus on specific metric, methodological, ethical, and technical issues associated with open source project health.

  7. Roles: Committees and Working Groups involve Contributors and Maintainers:

    1. Contributors: anyone in the community that contributes code, documentation, use cases, standardized metrics, or other community activities related to the Project;

    2. Maintainers: Contributors who have the ability to commit directly to a Project’s repository and are responsive to contributions or changes from Contributors. Maintainers are listed in the README of each repository.

  8. Participation in the Project, including contributions to any Committee or Working Group, is open to all under the terms of this Charter.

  9. The GB may (1) establish work flow procedures for the submission, approval, and closure/archiving of Committees and projects of Committees, (2) set requirements for the promotion to or removal from Committee roles, as applicable, and (3) amend, adjust, refine and/or eliminate the roles as it sees fit.

  10. The GB has 2 co-chairs that equally share the responsibility for setting the agenda and presiding over meetings of the GB. The Co-Chairs are voting members of the GB, and co-chairs cast their votes last. After each election, one new co-chair is selected via a vote by the GB from the newly elected board members who are starting a 2-year term and will serve as co-chair for their entire 2-year term. This is designed for continuity with the existing co-chair, having one year remaining as co-chair, with an overlap for knowledge sharing with the newly selected co-chair. If either co-chair needs to step down for any reason, a new co-chair will be selected from the existing GB via a vote by the GB. The newly selected GB member will serve as a co-chair for the time remaining for the co-chair who stepped down, or till the end of their term on the GB, whichever comes first.

  11. Responsibilities: The GB shall also be responsible for:

    1. coordinating the direction of the Project;

    2. establishing any project policies, including for the addition and removal of Maintainers and documenting any requirements for official project releases (Software or Metrics);

    3. approving project or system proposals (including, but not limited to, incubation, deprecation, and changes to a project’s charter or scope);

    4. establish policies related to intellectual property;

    5. creating Committees to focus on cross-project issues and requirements;

    6. facilitating communication and collaboration among Committees;

    7. communicating with external and industry organizations concerning Project matters;

    8. appointing representatives to work with other open source or open standards communities;

    9. establishing community norms, workflows, or policies including processes for contributing (to be published on the Project web site), issuing releases, and security issue reporting policies;

    10. discussing, seeking consensus, and where necessary, voting on matters relating to metrics or the code base that affect multiple projects; and

    11. coordinate any marketing, events, or communications with The Linux Foundation.

3. GB Voting

  1. While it is the goal of the Project to operate as a consensus based community, if any GB or Committee decision requires a vote to move forward, the respective voting members shall vote on a one vote per voting member basis.

  2. Quorum for GB and Committee meetings requires two-thirds of all voting members of the GB or a Committee, as applicable. The GB or any Committee may continue to meet if quorum is not met, but are prevented from making any decisions at the meeting. If quorum is not met, a second meeting with the same agenda can be called after two weeks to which quorum will become 1/2 of all voting members.

  3. Except as provided in Section 8.b(iv) and 9.a, decisions by vote at a meeting shall require a majority vote of those in attendance, provided quorum is met. Decisions made by electronic vote without a meeting shall require a majority of all voting members of the GB or a Committee, as applicable.

  4. In the event a vote cannot be resolved within a Committee, the GB may decide the matter. In the event that any vote cannot be resolved by the GB, any voting member on the GB is entitled to refer the matter to The Linux Foundation for assistance in reaching a decision.

4. Antitrust Guidelines

  1. All participants in the Project must abide by The Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy.

  2. All participants should encourage open participation from any organization able to meet the participation requirements, regardless of competitive interests. Put another way, the community may not seek to exclude any participant based on any criteria, requirements, or reasons other than those that are reasonable and applied on a non-discriminatory basis to all participants.

5. Code of Conduct

  1. The GB may adopt a fair, reasonable, and non-discriminatory Project code-of-conduct, with approval from The Linux Foundation as outlined below.

  2. The Project will operate in a transparent, open, collaborative, and ethical manner at all times.

  3. The output of all Project discussions, proposals, timelines, decisions, and status will be made open and easily visible to all.

  4. The current Project code of conduct can be found at (https://chaoss.community/about-2/code-of-conduct/).

6. Budget and Funding

  1. The GB will coordinate any budget or funding needs with The Linux Foundation. Organizations participating may be solicited to sponsor Project activities and infrastructure needs on a voluntary basis.

  2. The Project will not raise any funds and will be supported on a volunteer basis by the Project participants.

  3. Under no circumstances will The Linux Foundation be expected or required to undertake any action on behalf of the Project that is inconsistent with the tax-exempt purpose of The Linux Foundation.

7. General Rules and Operations

The Project should:

  1. engage in the work of the project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of The Linux Foundation in the open source software community;

  2. respect the rights of all trademark owners, including any branding and usage guidelines;

  3. engage The Linux Foundation for all Project press and analyst relations activities;

  4. upon request, provide information regarding Project participation, including information regarding attendance at Project-sponsored events, to The Linux Foundation; and

  5. coordinate with The Linux Foundation in relation to any websites created directly for the Project.

8. Intellectual Property Policy

  1. The Project seeks to integrate and contribute back to other open source projects within the mission set forth in Section 1 above. The Project also seeks to assure that relevant patentable innovations are made available without the need for any patent licenses. Based on this goal for the Project, the development community will:

    1. conform to all license requirements of the open source projects leveraged by the Project (such projects, collectively, “Upstream Projects”); and

    2. maximize opportunities for compatibility with other projects that might be leveraged by the Project.

  2. Except as described in Section 8.c, all code contributions to the Project are subject to the following:

    1. All new inbound code contributions must be accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org)

    2. All contributions of code will be received and made available under the GNU General Public License, Version 2 or later, or Version 3 or later.

    3. All contributions to implementation-agnostic metrics and standards, including associated scripts, SQL statements, and documentation, will be received and made available under the MIT License (https://opensource.org/licenses/MIT).

    4. The GB may approve the use of an alternative license for inbound or outbound contributions on an exception basis. Exceptions require a two-thirds approval of the entire GB.

  3. Upstream Project code contributions not stored within the Project’s main code repository must comply with the contribution process and license terms for the applicable Upstream Project

  4. The Project may engage The Linux Foundation to determine the availability of, and register, trademarks, service marks, which shall be owned by The Linux Foundation. Any Project-related domain names and trademarks will be owned by The Linux Foundation and any pre-existing Project-related domain names or trademarks shall be transferred to The Linux Foundation for use by the Project.

9. Amendments

  1. This charter may be amended by a two-thirds vote of the entire GB, subject to approval by The Linux Foundation to ensure the amendment is in-line with non-profit requirements and open source principles.