Contributors とは — OpenSSF Scorecard の見方

何を見るチェックか

Scorecard は、直近30コミット程度の作成者を調べ、その人たちが GitHub のプロフィールに登録している所属組織を数えます。

見ているのは人数ではなく、所属している組織の数です。同じ会社の10人より、別々の会社の3人のほうが高くなります。

この項目の狙いは、いわゆる「バス係数」—— 特定の1人や1社が抜けたときにプロジェクトが止まるか——の目安を取ることです。

点が低いということは、貢献者が特定の個人または組織に集中している可能性がある、という意味です。

実務で効いてくるのはこういう場面です。

つまりこの項目は、そのプロジェクトが今後も続くかの見通しに関するものです。現在の品質やセキュリティの話ではありません。

「貢献者が少ない＝質が低い」ではありません。ここは特に強く言っておきます。

世の中で最も広く使われている小さなライブラリの多くは、作者1人が長年きちんと保守しているものです。この項目では 0点になります。

さらに、次の理由でも低く出ます。

GitHub のプロフィールに所属組織を書いていない。 多くの開発者は空欄のままです。実際には複数の会社の人が関わっていても、組織が読み取れなければ数えられません。
直近30コミット程度しか見ていない。 たまたま1人が集中して作業した時期だと低く出ます。長期で見れば多様な貢献者がいることもあります。
1社が主導する OSS。 企業が開発している正当なプロジェクトでも、貢献者の所属が揃うと低くなります。

この項目は「品質」ではなく「継続性の見通し」として読んでください。 そして、Code-Review が低いプロジェクトの多くは、この項目も低いはずです。両方が低いなら、それは1人プロジェクトだという情報であって、 2つの別々の問題ではありません。

この項目を、**「そのライブラリが止まったとき、自分たちがどうするか」**を考えるきっかけとして使ってください。

実際の貢献者を見る。 リポジトリの Insights → Contributors で、長期の分布を確認します。 Scorecard が見ている30コミットより広い範囲が見えます。
組織が管理しているかを見る。 個人アカウントの下にあるのか、組織アカウントの下にあるのかで、引き継ぎの余地が変わります。
止まったときの代替を確認する。 同じ目的の別ライブラリがあるか、フォークして自前で保守できる規模か。 小さなライブラリなら、1人プロジェクトでもリスクは小さいです。コードが数百行なら、最悪自分で引き取れます。
大きく複雑なライブラリで、かつ貢献者が1人なら、そこは正直に見積もる。 これは品質の問題ではなく、事業継続の判断です。

この項目は、意図的に上げにいくものではありません。 貢献者の数は、無理に増やせるものでも、増やすべきものでもありません。

現実的にできることは次のとおりです。

GitHub のプロフィールに所属を書く。 実際に複数の組織から関わっているのに空欄で 0点、という状況は解消できます。
CONTRIBUTING.md を置く。 開発環境の作り方、テストの走らせ方、Pull Request の出し方を書いておくと、外部からの貢献の敷居が下がります。
good first issue を付ける。 最初の1歩の入口になります。
リポジトリを組織アカウントに移す。 1人であっても、将来の引き継ぎ先を作れる形にはなります。

そして最も価値があるのは、1人で保守していることを README に書くことです。

このライブラリは現在1名で保守しています。対応が遅れることがあります。

これがあれば、採用する側は Contributors と Code-Review の低さを正しく解釈でき、「情報が無いから避ける」ではなく「承知のうえで使う」という判断ができます。