Maintained とは — OpenSSF Scorecard の見方

何を見るチェックか

Scorecard は、直近90日間のリポジトリの動きを数えます。

見ているのは主に次の2つです。

どちらも一定数あれば高い点になり、まったく無ければ 0 になります。

また、リポジトリが Archived になっている場合は無条件で 0 点です。これは推測ではなく、メンテナー自身が「もう更新しない」と明示した状態なので、このチェックの中では最も確度の高い情報です。

なお、このチェックが見ているのは活動の量であって、活動の質ではありません。

点が低いということは、直近90日間に目立った動きが観測できなかったという意味です。

それが実際に問題になるのは、次のような場合です。

Archived の場合は意味が違います。 これは「動きがない」ではなく「もう更新しないと宣言されている」です。新規採用では、後継があるかを必ず確認してください。

「更新が少ない＝保守が止まっている」ではありません。この項目が最も誤読されます。

コミットが少ないのには、悪くない理由がいくつもあります。

逆に、コミット数が多いことが安心材料になるとも限りません。 自動更新ボットのコミットだけで数字が積み上がっている場合、人の目が入っているとは限らないためです。

判断するときは、数だけでなく **最後の変更が「何の変更だったか」**を見てください。機能追加が止まっていても、セキュリティ修正には反応している、というプロジェクトは健全です。

Archived かどうかを最初に見る。 ここだけは推測が要りません。 Archived なら、後継や移行先の案内が README にないかを確認します。
最後のコミットの中身を見る。 タイポ修正なのか、依存の更新なのか、セキュリティ修正なのかで意味が変わります。
未解決の Issue に、最近のものが混ざっていないかを見る。 数年前の Issue だけが並んでいるのか、最近の報告にも返信があるのかで印象は大きく変わります。
リリースの間隔を見る。 コミットが少なくても、年に1回きちんとリリースが出ているなら、生きているプロジェクトです。
依存の少なさを見る。 依存が無いライブラリは、そもそも更新の必要が起きにくく、更新が止まっていてもリスクが小さくなります。

無理にコミット数を増やす必要はありません。状態を明示するほうが効果的です。

完成しているなら、README にそう書く。 「このライブラリは機能的に完成しており、新機能の追加予定はありません。不具合とセキュリティの修正には対応します」と1段落あるだけで、読む側の不安はほとんど解消します。
メンテナンスを縮小するなら、その方針を書く。 対応する範囲（セキュリティのみ、など）を明示します。
開発を終えるなら、リポジトリを Archived にする。 放置よりずっと親切です。後継があるなら README の先頭に書きます。

Issue への返信も、このチェックの対象です。すぐ直せなくても「確認しました。対応は未定です」と返すだけで、プロジェクトが生きていることは伝わります。