CHAOSS Explained: Health Metrics, Metrics Models, Augur and GrimoireLab

CHAOSS (Community Health Analytics in Open Source Software) is a Linux Foundation project whose charter took effect on 1 September 2017. It publishes free, implementation agnostic definitions of open source community health metrics, groups them into metrics models for specific questions, and maintains software that computes them. Use it to judge whether a dependency's community can keep shipping fixes.

For a security team, CHAOSS answers a question vulnerability scanners do not: will the people behind this package still be there when the next CVE lands? This post covers how CHAOSS is organised, its metric families and metrics models, what GrimoireLab and the Augur lineage (now CollectOSS) collect, how it sits next to OpenSSF Scorecard, and a hands-on walkthrough that computes four metrics from git history and the GitHub REST API.

Key takeaways

• CHAOSS is a Linux Foundation project with a charter effective 1 September 2017. Its mission covers open source analytics software, implementation agnostic metrics and optional models and exchange formats.
• At the time of writing the CHAOSS knowledge base lists 89 released metrics and 17 released metrics models. A metric answers one question; a model combines several metrics to answer a harder one.
• Metric definitions are published under the MIT License, while code contributions are received under GPL 2.0 or later, or GPL 3.0 or later, unless the Governing Board approves an exception.
• "Bus Factor" is now called Contributor Absence Factor: the smallest number of people responsible for 50% of contributions. Elephant Factor applies the same arithmetic to organisations.
• For adopters, the most useful models are Starter Project Health, the OSS Project Viability Starter and the four OSS Project Viability models (Compliance and Security, Governance, Community, Strategy).
• Augur left the CHAOSS GitHub organisation in March 2026. CHAOSS now lists CollectOSS (a fork of Augur) and GrimoireLab as its software subprojects.
• OpenSSF Scorecard measures security practices in a repository; CHAOSS measures the people and processes around it. Use both, and use neither as a pass or fail gate on its own.
• Every CHAOSS metric page carries a privacy warning: health metrics are built from personal data, so GDPR, US state law and forge terms of service apply.

What is CHAOSS?

CHAOSS describes itself as "a Linux Foundation project focused on creating metrics, metrics models, and software" to understand open source community health. The acronym stands for Community Health Analytics in Open Source Software. The CHAOSS About page lists four goals: establish metrics and models for measuring community health, produce open source software for measuring it, develop programs for metrics that cannot be derived from trace data, and work with global partners on how community health is understood.

The formal starting point is the CHAOSS Project Charter, which states an effective date of 1 September 2017 and a last update of 14 January 2026. The charter's mission has three parts:

1. Produce integrated, open source software for analysing software development, along with the standards and models used in that software.
2. Establish implementation agnostic metrics for measuring community activity, contributions and health.
3. Optionally produce standardised metric exchange formats, detailed use cases, models or recommendations.

"Implementation agnostic" is the important phrase. A CHAOSS metric is a definition, not a script. Two tools can compute Time to First Response differently (maintainer replies only, or any human reply) and both stay faithful to the definition if they state the filter they used. So read the filter before you compare two numbers.

The About page names contributors, communities, companies and foundations as its audiences. Security teams are not named, but the risk metrics and viability models were written with dependency adopters in mind.

How is CHAOSS organised?

CHAOSS has a Governing Board, Working Groups, Chapters, Software Subprojects and a set of committees. The CHAOSS Governance page records its own history: approved by the Governing Board on 22 June 2023, with a governance diagram added on 2 January 2024, finance committee changes on 26 January 2026 and software subproject changes on 14 June 2026.

The board aims for consensus; when it votes, quorum is two thirds of voting members. Roles have published entry criteria: a Working Group chair needs at least six months of participation, and a maintainer needs at least five substantial pull request reviews and five merged pull requests as author.

Which working groups are active?

The CHAOSS Working Groups page lists one active Metrics Working Group, Diversity, Equity and Inclusion, which also runs the badging programme. The Context Working Groups are OSPO (run jointly with the OSPO community at todogroup.org), University and Academic (joint with the OSPO++ community), Science and Research, Data Science, UN Sustainable Development Goals, Funding Impact Measurement, Package Metadata, and Accessibility and Disability Inclusion.

Several groups that shaped the catalogue are now listed as inactive: Metrics Development (formerly Common Metrics), Metrics-Models, Evolution, Value and Risk. Older material that mentions "the Risk working group" describes work that now lives elsewhere. The Metrics Models working group repository records that the group started in August 2021.

How are metrics written and changed?

Every metric page in the CHAOSS knowledge base follows the same shape: a Question, an Overview, data collection strategies or a formula, Filters (time period, repository group, bots, role of responder), example visualisations, contributors, a stable citation URL of the form https://chaoss.community/?p=NNNN, a change request link to edit the definition on GitHub, and a privacy notice.

The pages we fetched did not describe a fixed release calendar, so treat the knowledge base as a living catalogue and record the stable URL and the date you read a definition when you cite it in a policy.

Who takes part?

Participation is open to anyone under the charter. The community meets in a weekly sync and working group calls, runs regional chapters such as CHAOSS Africa, and has held CHAOSScon events since 2018. The board's April 2026 public update put the Slack membership at roughly 3,500 people.

Which metric families does CHAOSS define?

The All Metrics index listed 89 released metrics when we fetched it. CHAOSS no longer organises them strictly by the old working group names, but the families below cover the catalogue and map to the questions adopters ask.

Four of these deserve a closer look because they are the ones adopters reach for first.

Contributor Absence Factor (formerly Bus Factor)

The Contributor Absence Factor page asks: "How high is the risk to a project should the most active people leave?" It is defined as the smallest number of contributors responsible for 50% of total contributions, and the page states that the metric "was previously called 'Bus Factor.'" A lower value means more dependence on fewer people.

CHAOSS gives a worked example with eight contributors whose contribution counts are 1000, 202, 90, 33, 332, 343, 42 and 433. Sorted in descending order they are 1000, 433, 343, 332, 202, 90, 42, 33. The total is 2,475, so the 50% threshold is 1,237.5. The first contributor alone has 1,000, which is below the threshold; the first two together have 1,433, which crosses it. The Contributor Absence Factor is therefore 2.

A second example with our own numbers: a library's last 12 months of commits by author are 410, 95, 60, 40, 30, 25, 20 and 20. The total is 700, the threshold is 350, and the top author alone has 410, so the factor is 1. Lose that person and more than half the year's work goes with them. CHAOSS lets you count commits, issues, comments or documentation, measured at regular intervals.

Elephant Factor

The Elephant Factor page asks: "What is the distribution of work in the community across companies?" It uses the same arithmetic as Contributor Absence Factor, applied to organisations: the minimum number of companies whose employees contribute a given percentage (typically 50%) of commits. The page's own example reuses the eight numbers above and arrives at an elephant factor of 2.

One caution about reading the page. Its overview sentence says a high elephant factor suggests reliance on a few contributors, but its formula and example produce a smaller number when fewer companies dominate. Go by the formula: an elephant factor of 1 means one organisation does at least half the work. The page also warns that a lifetime figure "may misrepresent the current level of organizational diversity," so compute it over a recent window. Our existing post on what elephant factor is and why it matters covers the interpretation side in more depth.

Time to First Response

The Time to First Response page asks how much time passes between an activity that needs attention (an issue, a pull request, an email) and the first response. Its data collection notes are explicit: collect the creation and first response timestamps, and "exclude responses from bots or other automated systems." Its filters include the role of the responder (for example, maintainers only), automated responses, and the type of activity. For issues specifically, CHAOSS also defines Issue Response Time.

Change Request Closure Ratio

The Change Request Closure Ratio page asks: "Is the project keeping up with change requests?" It compares the number of change requests (pull requests or merge requests) closed in a period with the number open in the same period. A high ratio means contributions are handled; a low one may mean an overloaded or shrinking maintainer team. Its filters include date ranges, bot exclusion, labels, bug fix versus feature, and accepted versus rejected closes. The page notes that GrimoireLab calls a closely related measure the Review Efficiency Index.

Libyears and Release Frequency

Two more metrics connect community health directly to patching. Libyears measures the cumulative age of a project's dependencies compared with their current stable releases, by release date rather than version number, and can be reported as a total, an average or a median. Release Frequency counts releases over time, including point releases that carry bug and security fixes, collected wherever the project actually publishes. Our guide to measuring dependency freshness from an SBOM with libyears shows the libyears calculation end to end.

What are metrics models, and which help adopters judge a dependency?

The CHAOSS metrics and metrics models page draws the line clearly: metrics are "meant to answer one single question," while metrics models are "collections of metrics that are brought together to provide deeper context and answer more complex questions." The All Metrics Models index listed 17 released models when we fetched it, including Community Activity, Community Welcomingness, Funding, Project Engagement and Safety. Seven were written with a dependency adopter's question in mind.

The Business Readiness model is an eighth candidate, grouping code quality, license and risk metrics (including Contributor Absence Factor and Elephant Factor) for OSPO managers.

What the model authors say about interpretation

• The Starter Project Health model came out of a corporate OSPO with repositories spread across a few dozen GitHub organisations. Its authors say they "do not compare projects against each other," and use the metrics for per project improvement. Their internal guideline was a human response to every pull request within two business days, and they look at trends rather than single readings.
• The same model warns that bots can distort Time to First Response and Change Request Closure Ratio, that informational repositories may have no releases at all, and that some projects publish releases on a package registry rather than the forge.
• The Viability models came out of an OSPO in a regulated telecom setting. They stress that "viability" thresholds differ by organisation: a smaller organisation may accept a Contributor Absence Factor of 2, while a larger one would expect much higher values.
• The Viability: Community model says an absolute committer threshold is close to useless, but a project that "has shed 90% of its committers in a three month period" is in trouble. Trends beat snapshots.

The practitioner guides

CHAOSS also publishes practitioner guides (Assessing Viability, Responsiveness, Security, Sunsetting and others). The Security practitioner guide points readers to the OpenSSF Best Practices badge, Libyears and Release Frequency, and lists OpenSSF Scorecard as "not a CHAOSS metric, but a tool that collects many security metrics." It explains that there is no CHAOSS metric for time to resolve vulnerabilities because separating security issues from other bugs is hard to do consistently. The introduction guide advises against comparing projects with each other and, if you must, comparing only projects with similar characteristics.

What do Augur, CollectOSS and GrimoireLab do?

What happened to Augur?

According to the CHAOSS board's public update of 13 April 2026, on 29 March 2026 one of the project's co-founders moved Augur from the CHAOSS GitHub organisation to a separate organisation called AugurLabs, citing governance concerns. The README now served from the chaoss/augur repository states that the board later acknowledged that Augur "is no longer part of CHAOSS" and points users to CollectOSS, "based on a fork of the Augur code," whose initial 1.0.0 release is intended to be "as drop-in of a migration as possible." The governance page updated on 14 June 2026 lists CollectOSS and GrimoireLab as the CHAOSS software subprojects.

If your team runs Augur, decide which line you follow; CollectOSS publishes a migration guide. References elsewhere lag: the 8Knot README still says its data comes from Augur, while the CHAOSS Software page presents 8Knot as the dashboard for CollectOSS. The board framed the episode as a breakdown of trust, a reminder that governance events are part of community health too.

CollectOSS (the Augur line inside CHAOSS)

The CollectOSS README describes it as a software suite for collecting structured data about free and open source communities via git forges. Key facts from its README and the CHAOSS Software page:

• Forge data (commits, issues, pull requests, reviews, comments, releases) from GitHub and GitLab, with Forgejo described as coming soon, stored in PostgreSQL for custom SQL.
• The CHAOSS Software page says its parallel collection runs in production "with over 40,000 repositories" and supports rotating API keys.
• Beyond activity counts it records license coverage and license type, COCOMO based complexity and replacement cost estimates, dependency scanning, dependency Libyears and time series OpenSSF Scorecard results.
• It ships as container images under the MIT License. Install by cloning, copying environment.txt to .env, filling in the variables and running docker compose up. Dashboards come from 8Knot, a Dash and Plotly app.

GrimoireLab

The GrimoireLab README calls it "a CHAOSS toolset for software development analytics" that retrieves data from the systems used to build software, stores it, enriches it with metrics and supports analytics and visualisation. Its components, from the GrimoireLab website:

• Perceval retrieves data. Its README lists backends for git, GitHub, GitLab, Gerrit, Bugzilla, Jira, Discourse, mailing list archives, Stack Exchange, Slack, Mattermost, Jenkins, Confluence, MediaWiki and more, plus community backends such as Bitbucket and Zulip.
• Arthur schedules and runs Perceval jobs, with incremental updates and parallel downloads.
• Graal extends the git backend with pluggable source code analysis.
• GrimoireELK enriches raw data and loads it into the search store.
• SortingHat manages identities: it merges one person's accounts across data sources and records organisational affiliation. Affiliation is what makes Elephant Factor computable, and identity merging is what keeps Contributor Absence Factor honest when one person commits from three email addresses.
• Sigils provides prebuilt dashboard panels for OpenSearch Dashboards.

The CHAOSS Software page adds that GrimoireLab reads 30+ data sources, offers "onion analysis" of core, regular and casual contributors, attraction and retention metrics, network analysis across projects and organisations, OpenSearch API access for tools such as Jupyter, and that "data privacy is built in to support GDPR compliant operation."

The quick start uses Docker Compose: clone the repository, run docker compose up -d in the docker-compose folder, and open OpenSearch Dashboards on port 8000. The README asks for 2 CPU cores, 8 GB of RAM and enough virtual memory for OpenSearch, and says data for a small repository is usually ready in 10 to 15 minutes. The default setup ships with a known admin password in docker-compose.yml; change it before you expose the stack beyond your laptop.

CollectOSS or GrimoireLab?

How do OSPOs and adopters use CHAOSS next to OpenSSF Scorecard?

The two answer different questions. OpenSSF Scorecard is "an automated tool that assesses a number of important heuristics ('checks') associated with software security" and gives each check a score from 0 to 10. Its aggregate score is a weighted average in which Critical risk checks weigh 10, High 7.5, Medium 5 and Low 2.5. Scorecard scans more than 1.3 million repositories every week and publishes results through a REST API; its README notes that the BigQuery public dataset is no longer available. Our explainer on what OpenSSF Scorecard measures walks through each check.

Two Scorecard checks overlap with CHAOSS ground, and the Scorecard checks documentation shows how differently they are built:

• Contributors (Low risk) looks at the Company field on GitHub profiles for authors of recent commits. Full marks need contributors from at least three companies in the last 30 commits, each with at least five of those commits. That is a coarse cousin of Elephant Factor.
• Maintained (High risk) gives full marks for at least one commit per week over the previous 90 days and the lowest score to archived projects. Its documentation adds that a lack of activity "is not necessarily always a problem" for small utilities. Our post on what the 90 day Maintained check means explores this.

Scorecard's own non-goals are worth quoting to anyone who wants a single number: it is not meant "to be a definitive report," its checks "are heuristics" with false positives and false negatives, and aggregate scores tell you "nothing about what individual behaviors a repository is or is not doing." See also does a low OpenSSF Scorecard score mean a package is unsafe.

A workable OSPO pattern looks like this:

1. Inventory first, from an SBOM of each product.
2. Security practice signals: Scorecard results and OpenSSF Best Practices badge status (the badge is itself a CHAOSS metric).
3. Community health signals: the Starter Project Health or Viability Starter metrics for critical dependencies.
4. Context: small finished utility, framework, foundation project or single vendor project.
5. Decision and owner: accept, watch, contribute or fund, replace, or plan to fork.

Our posts on using OpenSSF Scorecard in a dependency approval process and OSPO metrics with goal, question, metric for dependencies go deeper on steps 2 and 5.

How do CHAOSS metrics compare with Scorecard, deps.dev and ecosyste.ms?

The deps.dev documentation describes the service as examining each package and constructing "a full, detailed graph of its dependencies and their properties." The ecosyste.ms home page describes "free services and tools for developers, researchers and policymakers to help identify, secure and sustain open source software," and showed about 15.2 million packages and 349 million repositories indexed on the day we checked; treat those counts as a moving snapshot. Our posts on researching a package in five minutes with deps.dev and open source dependency health metrics show how these sources fit together.

Step by step: compute four CHAOSS metrics for a dependency

This walkthrough computes Contributor Absence Factor, an approximate Elephant Factor, Time to First Response and Change Request Closure Ratio, plus Release Frequency, for one GitHub hosted dependency using git, curl, jq and awk. Keep the output with the date you ran it.

Step 0: set variables and a token

Unauthenticated GitHub REST API calls are limited to 60 requests per hour; an authenticated user gets 5,000 per hour, according to the GitHub rate limit documentation. Use a fine-grained token with read access to public repositories.

export OWNER=expressjs
export REPO=express
export GITHUB_TOKEN=your_read_only_token
export SINCE=$(date -u -v-12m +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '12 months ago' +%Y-%m-%dT%H:%M:%SZ)
gh_api() {
  curl -sS -H "Authorization: Bearer $GITHUB_TOKEN" \
       -H "Accept: application/vnd.github+json" "$@"
}

Step 1: Contributor Absence Factor from git history

Clone without file contents to keep it fast, then count non-merge commits per author over the last 12 months with git shortlog (-s summarises, -n sorts by count, -e shows emails).

git clone --filter=blob:none --quiet "https://github.com/$OWNER/$REPO.git"
cd "$REPO"
git shortlog -sne --no-merges --since="12 months ago" HEAD > ../authors.txt
head -10 ../authors.txt

# Smallest number of authors whose commits reach 50% of the total
awk '{print $1}' ../authors.txt | sort -rn | awk '
  { c[NR]=$1; total+=$1 }
  END { half=total*0.5; run=0
        for (i=1; i<=NR; i++) { run+=c[i]; if (run>=half) { print "authors:", NR, "commits:", total, "contributor_absence_factor:", i; exit } } }'

Before you trust the number, check authors.txt for the same person under two emails and for bot accounts (names ending in [bot]). Merge duplicates with a .mailmap file, which git shortlog honours, and drop bots. CHAOSS lets you count other contribution types too, so for a project where most work is review, repeat the count over pull request reviews.

Step 2: an approximate Elephant Factor from email domains

True Elephant Factor needs organisational affiliation, which is what SortingHat manages. A rough first pass groups commit authors by email domain:

git log --no-merges --since="12 months ago" --format='%ae' HEAD \
  | awk -F@ '{print tolower($2)}' | sort | uniq -c | sort -rn > ../domains.txt
cat ../domains.txt

awk '{print $1}' ../domains.txt | awk '
  { c[NR]=$1; total+=$1 }
  END { half=total*0.5; run=0
        for (i=1; i<=NR; i++) { run+=c[i]; if (run>=half) { print "elephant_factor_by_domain:", i; exit } } }'

Treat the result as a hypothesis. Personal mail domains and the forge's no-reply domain hide employers, and many people commit from personal addresses on company time. If users.noreply.github.com or a webmail domain sits at the top, you need affiliation data before you can say anything about company concentration.

Step 3: Time to First Response for recent issues

The GitHub issues endpoint returns pull requests as well as issues ("GitHub's REST API considers every pull request an issue"), so filter on the pull_request field. For each issue, fetch its comments and take the first one not written by the author or a bot.

gh_api "https://api.github.com/repos/$OWNER/$REPO/issues?state=all&since=$SINCE&per_page=100" \
  | jq -c '.[] | select(.pull_request | not) | {n: .number, author: .user.login, created: .created_at}' \
  > ../issues.jsonl

while read -r row; do
  n=$(echo "$row" | jq -r .n); author=$(echo "$row" | jq -r .author); created=$(echo "$row" | jq -r .created)
  first=$(gh_api "https://api.github.com/repos/$OWNER/$REPO/issues/$n/comments?per_page=100" \
    | jq -r --arg a "$author" '[.[] | select(.user.type != "Bot" and .user.login != $a)] | .[0].created_at // empty')
  if [ -n "$first" ]; then
    jq -n --arg c "$created" --arg f "$first" '(($f|fromdateiso8601) - ($c|fromdateiso8601)) / 3600'
  else
    echo "no_response"
  fi
done < ../issues.jsonl > ../ttfr_hours.txt

grep -v no_response ../ttfr_hours.txt | sort -n | awk '{a[NR]=$1} END {print "responded:", NR, "median_hours:", (NR%2 ? a[(NR+1)/2] : (a[NR/2]+a[NR/2+1])/2)}'
echo "no response yet: $(grep -c no_response ../ttfr_hours.txt)"

This reads one page of 100 issues; paginate for busy projects. Report the median and the count of unanswered issues, since an average is dragged around by a few old outliers.

Step 4: Change Request Closure Ratio for the last 90 days

CHAOSS defines the ratio as change requests closed during a period against change requests open during the same period. Using the pulls endpoint with state=all:

P90=$(date -u -v-90d +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)

# Closed in the window (merged or not), newest activity first
gh_api "https://api.github.com/repos/$OWNER/$REPO/pulls?state=closed&sort=updated&direction=desc&per_page=100" > ../closed.json
CLOSED=$(jq --arg p "$P90" '[.[] | select(.user.type != "Bot") | select(.closed_at >= $p)] | length' ../closed.json)

# Still open now (these were open during the window)
gh_api "https://api.github.com/repos/$OWNER/$REPO/pulls?state=open&per_page=100" > ../open.json
STILL_OPEN=$(jq '[.[] | select(.user.type != "Bot")] | length' ../open.json)

# Open at some point in the window = still open + closed during the window
awk -v c="$CLOSED" -v o="$STILL_OPEN" 'BEGIN { printf "closed: %d  open_during_window: %d  closure_ratio: %.2f\n", c, o + c, c / (o + c) }'

Both calls fetch one page of 100; add the page parameter for busy projects. Record whether you excluded bots (dependency update bots can open a large share of pull requests) and whether you counted rejected closes, because CHAOSS lists both as filters.

Step 5 (bonus): Release Frequency

gh_api "https://api.github.com/repos/$OWNER/$REPO/releases?per_page=100" \
  | jq --arg s "$SINCE" '[ .[] | select(.draft | not) | select(.published_at >= $s) ] | length'

# Some projects tag without creating forge releases
git tag --sort=-creatordate --format='%(creatordate:short) %(refname:short)' | head -20

The releases endpoint only sees releases created on the forge. If the project publishes mainly to npm, PyPI or Maven Central, count versions there instead, as the CHAOSS definition suggests.

Step 6: interpret the results

The Starter Project Health authors' advice applies here: look at trends, and read each metric in light of what the project is. A single reading is a prompt to look closer. Our post on maintainer health signals before adopting a dependency suggests what to look at next.

What are the pitfalls?

Goodhart's law and gaming

Goodhart's law is usually stated as "when a measure becomes a target, it ceases to be a good measure" (summary). Every metric in this post can be gamed once it becomes a target. Time to First Response drops if a bot or a maintainer posts "thanks, we'll look" on every issue, which is exactly why CHAOSS tells you to filter automated responses and lets you count maintainer replies only. Change Request Closure Ratio rises if maintainers close contributions without review. Commit counts rise if work is split into smaller commits. Contributor Absence Factor can be nudged up by spreading the same work across more accounts.

The defence is to keep metrics diagnostic: use them to ask questions about a dependency, never to rank maintainers.

Privacy and GDPR

Health metrics are computed from personal data such as names, emails, timestamps and employer affiliation. Every CHAOSS metric page carries the same warning: "The usage and dissemination of health metrics may lead to privacy violations," with risks from GDPR in the EU, state law in the US, other laws and the terms of service of providers such as GitHub and GitLab. In GrimoireLab, SortingHat holds identities and affiliations, so access control and retention decisions belong there.

CHAOSS applies this to itself. Its Data Policies page says contributor data in public channels such as git logs, issues and mailing lists is part of the public record and licensed under MIT, while non-public PII is restricted to specific team members, stored securely and deleted within two months after the reason for collecting it ends. For your own programme: compute at the project level, avoid publishing per person rankings, store affiliation data with access controls, and set a retention period.

Comparing unlike projects

The CHAOSS introduction guide gives the examples: JavaScript projects differ from C and C++ projects, foundation owned projects differ from corporate ones, and a project the size of Kubernetes looks nothing like a small library. A Release Frequency of two per year is alarming for a web framework and normal for a parsing library that is essentially finished.

Data quality traps

• Bots inflate activity and deflate response times.
• Mirrors: some projects develop on their own forge or mailing list and mirror to GitHub, so the GitHub data shows almost nothing.
• Monorepos and multi-repo projects need the repository group filter that CHAOSS recommends.
• Identity splits: one person with three emails looks like three contributors and makes Contributor Absence Factor look better than it is.
• Window choice: lifetime figures hide recent change, which the Elephant Factor page warns about directly.

Governance extras: badging and licensing

DEI badging

CHAOSS runs two badging programmes. DEI Event Badging is itself a released metrics model: events are peer reviewed against metrics such as Code of Conduct at Event, Diversity Access Tickets and Family Friendliness, and earn a badge level that reflects how many they meet, according to the DEI Event Badging model page.

DEI Project Badging is for repositories. According to the project badging README, a project submits a repository containing a DEI.md file, a scanner bot checks it for the required content, and the project receives a markdown snippet for its README. One level, Bronze, is available, and its requirement is the presence of a DEI.md file. The CHAOSS community repository displays this badge for CHAOSS itself. A badge like this signals that a project has written down its approach; it is not a measurement of outcomes.

Licence of the metric definitions

The charter's intellectual property section says contributions to "implementation-agnostic metrics and standards, including associated scripts, SQL statements, and documentation" are received and published under the MIT License, while code contributions are received under GPL 2.0 or later, or GPL 3.0 or later. The board can approve exceptions with a two thirds vote of the entire board, and CollectOSS's README states that it is MIT licensed, so check each repository's licence file. New code contributions need a Developer Certificate of Origin sign-off. For adopters, that means you can reuse a metric definition in an internal policy or tool under MIT terms.

Common mistakes

• Using lifetime numbers. Compute over the last 6 or 12 months and track the trend.
• Not removing bots. Dependency update bots and triage bots distort activity, response time and closure ratio.
• Counting identities, not people. Merge aliases with .mailmap or SortingHat before computing concentration metrics.
• Reading Elephant Factor from email domains as fact. Personal and no-reply addresses hide employers.
• Treating "previously Bus Factor" as a different metric. Contributor Absence Factor is the same idea under a new name; update internal documents so two teams do not compute two versions.
• Assuming the forge is the whole project. Mailing lists, Gerrit, chat and package registries may carry most of the activity.
• Citing Augur documentation without checking which line you run. Augur moved out of CHAOSS in 2026; CollectOSS is the CHAOSS continuation.
• Publishing per person rankings. That creates privacy exposure and invites gaming.
• Confusing health with security. A lively, responsive community can still ship a vulnerable version today.
• Blocking a dependency on one threshold. Scorecard says its aggregate hides individual behaviours, and the CHAOSS Viability models say thresholds vary by organisation. Use metrics to trigger review, then decide with context.

FAQ

What does CHAOSS stand for?

Community Health Analytics in Open Source Software, as the CHAOSS About page spells it out. The charter uses the slightly shorter form "Community Health Analytics Open Source Software."

When did CHAOSS start?

The CHAOSS Project Charter states an effective date of 1 September 2017. CHAOSScon events have run since 2018.

What is the difference between a CHAOSS metric and a metrics model?

A metric answers a single question, such as how long it takes to get a first response. A metrics model combines several metrics to answer a harder question, such as whether a project is viable as a dependency.

What replaced Bus Factor in CHAOSS?

Contributor Absence Factor. The CHAOSS page says the metric "was previously called 'Bus Factor.'" It is the smallest number of contributors responsible for 50% of contributions.

Is Augur still a CHAOSS project?

No. In March 2026 Augur moved to a separate GitHub organisation, AugurLabs. CHAOSS continues the work as CollectOSS, a fork of Augur, and lists CollectOSS and GrimoireLab as its software subprojects.

Is OpenSSF Scorecard a CHAOSS metric?

No. The CHAOSS Security practitioner guide calls Scorecard "not a CHAOSS metric, but a tool that collects many security metrics." The OpenSSF Best Practices badge, however, is a CHAOSS metric.

Can CHAOSS metrics tell me whether a package is safe?

No. They tell you about the community that maintains it. Safety needs vulnerability data, an inventory of where the package is used and a view of how it is used.

Are CHAOSS metric definitions free to reuse?

Yes. Contributions to metrics and standards, including associated scripts, SQL and documentation, are published under the MIT License.

Where Safeguard fits, honestly

Safeguard does not compute CHAOSS metrics, run GrimoireLab or CollectOSS, or score community health. What it does sits next to this work. Safeguard generates and analyses SBOMs for repositories, container images and SBOM files, so you have the inventory that step 1 of any OSPO review needs. The platform shows which projects contain a given component and version, which is how you find every place a dependency with a worrying Contributor Absence Factor is used. It matches components against vulnerability databases, ranks findings with reachability analysis, evaluates license policies (parsing SPDX expressions and classifying licenses), and enforces policies and gates in CI. When a community signal turns into a decision to move off a version, autonomous remediation can open the upgrade pull request; it ships switched off, so your team chooses what runs on its own.

The fit is indirect. CHAOSS tells you whether people will keep fixing a dependency; Safeguard tells you where that dependency is, what is known to be wrong with it and how to change the version you ship.

Community health is a reasonable signal of how long you may wait for a fix when a vulnerability lands in a dependency. A project with a Contributor Absence Factor of 1 and no release this year is where that wait grows, and the section below is about closing the gap.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. The assistant reads a finding and its advisory, asks before any command that changes something, edits package.json to a fixed lodash version and runs npm install and npm test with your approval, then shows /permissions, /model and /scan .. The same session is where you would scan a repository to list the dependencies whose communities you then assess with the CHAOSS walkthrough above.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and scans from the terminal. Running scans locally keeps source code and SBOMs on your hardware, which suits an OSPO that wants to join scan results with health metrics it computes in-house.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask which of your projects contain a given component and version, then decide whether that dependency's community health justifies a replacement plan.

Click through it at your own pace, or open it full screen.

To try the CLI yourself, download Safeguard and follow the CLI documentation.

Quick check

Sources

• CHAOSS: About
• CHAOSS Project Charter
• CHAOSS Governance
• CHAOSS Working Groups
• CHAOSS Metrics and Metrics Models
• CHAOSS: All Metrics
• CHAOSS: All Metrics Models
• Metric: Contributor Absence Factor
• Metric: Elephant Factor
• Metric: Time to First Response
• Metric: Issue Response Time
• Metric: Change Request Closure Ratio
• Metric: Libyears
• Metric: Release Frequency
• Metrics Model: Starter Project Health
• Metrics Model: OSS Project Viability Starter
• Metrics Model: OSS Project Viability: Compliance + Security
• Metrics Model: OSS Project Viability: Governance
• Metrics Model: OSS Project Viability: Community
• Metrics Model: OSS Project Viability: Strategy
• Metrics Model: Development Responsiveness
• Metrics Model: Business Readiness of an Open Source Project
• Metrics Model: DEI Event Badging
• CHAOSS Practitioner Guide: Introduction
• CHAOSS Practitioner Guide: Security
• CHAOSS Software
• CHAOSS Data Policies
• CHAOSS: Public Update on Recent Events at CHAOSS (13 April 2026)
• chaoss/augur README
• CollectOSS README
• GrimoireLab README
• GrimoireLab website
• Perceval README
• 8Knot README
• CHAOSS community repository README
• CHAOSS Metrics Models working group README
• DEI Project Badging README
• OpenSSF Scorecard README
• OpenSSF Scorecard checks documentation
• deps.dev documentation
• ecosyste.ms
• GitHub REST API: Issues
• GitHub REST API: Issue comments
• GitHub REST API: Pulls
• GitHub REST API: Releases
• GitHub REST API: Rate limits
• git-shortlog documentation
• Goodhart's law (summary)

Last reviewed: 25 October 2026.