CHAOSS Project Charter  ## Metadata - Author: [[CHAOSS]] - Full Title: CHAOSS Project Charter - Category: #articles - Document Note: --- tags: - #open_source_governance - #project_charter - #community_health Author: CHAOSS Source: CHAOSS website Reference: https://chaoss.community/charter/ date created: 2025-08-22 00:00 --- # Title: CHAOSS Project Charter – Governance, Metrics, and Community Health Oversight ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🎯 Mission](#-mission) - [🏛️ Governance Board (GB)](#-governance-board-gb) - [👥 Roles: Contributors and Maintainers](#-roles-contributors-and-maintainers) - [🗳️ Voting Rules](#-voting-rules) - [🤝 Antitrust Guidelines](#-antitrust-guidelines) - [🧭 Code of Conduct](#-code-of-conduct) - [💰 Budget and Funding](#-budget-and-funding) - [⚙️ General Operations](#-general-operations) - [📜 Intellectual Property Policy](#-intellectual-property-policy) - [🗒️ Notes](#-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - The Linux Foundation Antitrust Policy: http://www.linuxfoundation.org/antitrust-policy - Developer Certificate of Origin: http://developercertificate.org - MIT License: https://opensource.org/licenses/MIT - CHAOSS Code of Conduct: https://chaoss.community/about-2/code-of-conduct/ - CHAOSS Project Charter: https://chaoss.community/charter/ ## 📝 Summary: The CHAOSS Project Charter defines the mission, governance, roles, processes, and policies for the Community Health Analytics Open Source Software (CHAOSS) project under The Linux Foundation. It sets out a dual-pronged mission: building integrated open source software and establishing implementation-agnostic community health metrics and standards. Governance is led by a Governance Board (GB) coordinating two core committees—Software and Metrics—plus working groups. The Charter outlines transparent processes, open participation, voting rules, antitrust safeguards, a code of conduct, volunteer-based funding, operational policies, and a clear IP regime (GPL for software, MIT for metrics/standards, DCO sign-offs, and Linux Foundation ownership of trademarks). ## 📖 Main Content: ### 🎯 Mission - Produce integrated open source software for analyzing software development and define standards/models for specific use cases. - Establish implementation-agnostic metrics for measuring community activity, contributions, and health. - Optionally produce standardized metric exchange formats, detailed use cases, models, or recommendations for industry issues. Direct reference: - “produce integrated, open source software for analyzing software development...” - “establish implementation-agnostic metrics...” - “optionally produce standardized metric exchange formats...” ### 🏛️ Governance Board (GB) - Responsible for overall oversight, coordinating Technical Committees and Working Groups. - Initial GB voting members were listed on the CHAOSS website, with procedures to be defined for future selection from the community. - Transparency commitments: publish public minutes; meetings open to the public; can be electronic or in person. - Committees: - Software Committee: technical oversight of coding projects. - Metrics Committee: collection and development of technology-agnostic metrics and standards. - Working Groups focus on specific metric, methodological, ethical, and technical topics. - Annual election of GB Chair and Co-Chair; both Software and Metrics Committees must be represented. - Responsibilities include: direction setting, policies (maintainer addition/removal, release requirements), project approvals, IP policies, cross-project committees, communication and collaboration, external liaison, community norms (including contribution processes and security reporting), multi-project decisions, and coordination with The Linux Foundation on marketing/events. ### 👥 Roles: Contributors and Maintainers - Contributors: anyone contributing code, docs, use cases, standardized metrics, or other community activities. - Maintainers: contributors with commit rights, responsive to changes; listed in each repository README. ### 🗳️ Voting Rules - Strive for consensus; when voting is necessary, one vote per voting member. - Quorum: two-thirds of voting members; if not met, a second meeting after two weeks may proceed with one-half quorum. - Decisions: simple majority of attendees (with quorum) for meetings; majority of all voting members for electronic votes, except for specific exceptions requiring higher thresholds. - Escalation: unresolved committee votes can be decided by GB; unresolved GB votes can be referred to The Linux Foundation. ### 🤝 Antitrust Guidelines - All participants must abide by The Linux Foundation Antitrust Policy. - Encourage open participation regardless of competitive interests; no exclusion on discriminatory or unreasonable bases. ### 🧭 Code of Conduct - GB may adopt a fair, reasonable, non-discriminatory code of conduct (subject to Linux Foundation approval). - Operations are transparent, open, collaborative, and ethical. - Outputs (discussions, proposals, timelines, decisions, status) are open and visible. - Current CoC is published on the CHAOSS site. ### 💰 Budget and Funding - GB coordinates budget/funding needs with The Linux Foundation. - Participation is volunteer-based; the Project does not raise funds itself. - The Linux Foundation won’t undertake actions inconsistent with its tax-exempt purpose. ### ⚙️ General Operations - Professional engagement maintaining a cohesive community and protecting The Linux Foundation’s esteem. - Respect rights of trademark owners and branding guidelines. - Engage The Linux Foundation for press/analyst relations. - Provide participation info on request (e.g., event attendance). - Coordinate any project websites with The Linux Foundation. ### 📜 Intellectual Property Policy - Integrate and contribute back to upstream projects; aim to make patentable innovations available without patent licenses. - Conform to licenses of upstream projects; maximize compatibility. - Inbound contributions: - DCO sign-off required. - Code contributions: GPL v2+ or v3+. - Metrics/standards (including scripts, SQL, docs): MIT License. - GB may approve exceptions by two-thirds of entire GB. - Upstream contributions outside the main repo must follow the upstream’s process and license. - Trademarks and domains owned/registered by The Linux Foundation; pre-existing project marks/domains transferred to The Linux Foundation. ### 🗒️ Notes - Mission blends tooling and standardization, positioning CHAOSS as both a software and a metrics/standards hub. - Governance emphasizes transparency and open meetings—strong signal for community trust-building. - Dual-committee model (Software and Metrics) ensures technical and methodological rigor while coordinating via GB. - Working groups are modular and community-driven—good for scalability and specialization. - Clear contributor/maintainer definitions ease onboarding and accountability. - Voting and quorum rules balance consensus culture with decision efficiency. - Antitrust and CoC frameworks align with industry best practices and legal compliance. - Volunteer funding model encourages broad participation; reliance on LF coordination ensures institutional alignment. - IP split (GPL for software, MIT for metrics/standards) is pragmatic: copyleft for code, permissive for artifacts to maximize adoption. - Trademark ownership by LF protects brand integrity and continuity. ## 📖 References: - CHAOSS Project Charter: https://chaoss.community/charter/ - CHAOSS Code of Conduct: https: - Summary: The CHAOSS Project Charter establishes the responsibilities and procedures for contributing to and overseeing the CHAOSS Project within The Linux Foundation. The mission of the project is to produce open-source software for analyzing software development and defining standards and models used in that software. The Governance Board is responsible for overseeing the project and coordinating the efforts of the Technical Committees and Working Groups. Participation in the project is open to all, and decisions are made by voting members. The charter also includes guidelines for antitrust, a code of conduct, budget and funding, intellectual property, and general rules and operations. The charter can be amended by a vote of the Governance Board. - URL: https://chaoss.community/charter/ **The Linux Foundation** **CHAOSS – Community Health Analytics Open Source Software** **Project Charter (the “Charter”)** **Effective: Sept 1, 2017** 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. At inception of the Project, the GB voting members consists of those individuals identified on the Project website (<https://chaoss.community>). Following inception of the Project, the GB will implement procedures and methodologies for the selection of GB voting members from the contributing community. 3. 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. 4. 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). The Committees of the Project are the “Software Committee,” responsible for technical oversight of inbound and outbound coding projects, and the “Metrics Committee,” responsible for the collection of technology-agnostic metrics and standards to be developed by the Project, and the GB shall provide coordination of the interrelationship between the Software and Metrics Committees. 5. 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. 6. 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. 7. Participation in the Project, including contributions to any Committee or Working Group, is open to all under the terms of this Charter. 8. 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. 9. The GB shall annually elect a GB Chair and GB Co-Chair from representatives involved in either or both the Software or Metrics Committees, such that both the Software and Metrics Committees will be represented by the Co-Chairs. The Chair and Co-Chair will set the agenda and preside over meetings of the GB. 10. 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., CHAOSS Project Charter, CHAOSS, 01h4ea0v5ydd8tdex8jhrrj5y3.