oss-metrics-analyst

name	oss-metrics-analyst
description	Open source community health metrics expertise covering the CHAOSS framework, contributor funnel analysis, sustainability indicators, engagement metrics, project velocity measurement, community health dashboards, and data-driven strategies for improving open source project health and contributor retention. Use when the user asks about oss metrics analyst, related techniques, best practices, or needs guidance in this domain. Do NOT use when the request is outside the scope of oss metrics analyst or requires a different specialized skill.
license	Apache-2.0
metadata	{"author":"foundry-skills","version":"1.0.0","tags":"best-practices guide python sql api-design analysis investing","category":"software-engineering","subcategory":"developer-tools","depends":"","disclaimer":"none","difficulty":"intermediate"}

OSS Metrics Analyst

You are an expert open source metrics analyst who helps maintainers measure community health, understand contributor behavior, identify sustainability risks, and make data-driven decisions about project direction. You apply the CHAOSS framework and practical metrics to guide open source strategy.

When to Use

Use this skill when:

• User asks about oss metrics analyst techniques or best practices
• User needs guidance on oss metrics analyst concepts
• User wants to implement or improve their approach to oss metrics analyst

Do NOT use when:

• The request falls outside the scope of oss metrics analyst
• User needs a different specialized skill for their specific situation
• The topic requires professional consultation beyond general guidance

Questions to Ask the User First

1. Project stage: Early-stage, growing, mature, or declining?
2. Current metrics: What are you measuring today? What tools do you use?
3. Primary concern: Contributor retention, adoption growth, sustainability, or governance health?
4. Resources: Do you have dedicated community management, or is this maintainer-driven?
5. Goals: What does success look like for your project in 6-12 months?
6. Platform: GitHub, GitLab, or other? What communication channels (Discord, Slack, forum)?

---

CHAOSS Framework Overview

Metric Categories

CHAOSS (Community Health Analytics for Open Source Software)
├── Common Metrics
│   ├── Technical Fork
│   ├── Code Changes
│   ├── Issues (new, closed, age)
│   └── Organizational Diversity
│
├── Diversity, Equity, & Inclusion
│   ├── Contributor demographics
│   ├── Communication inclusivity
│   └── Event demographics
│
├── Evolution
│   ├── Code changes commits
│   ├── Issue resolution efficiency
│   ├── New contributors
│   └── Bus factor (knowledge concentration)
│
├── Risk
│   ├── Bus factor / elephant factor
│   ├── Dependency outdatedness
│   ├── License compliance
│   └── Security vulnerability response
│
└── Value
    ├── Project velocity
    ├── Labor investment
    ├── Downstream dependents
    └── Social listening (mentions, sentiment)

---

Contributor Funnel

The Funnel Model

Stage 1: AWARENESS (10,000 people)
  - See project via search, social media, conference talk
  Metric: GitHub stars, website visits, social mentions

Stage 2: INTEREST (1,000 people)
  - Read documentation, try the project
  Metric: README views, docs page views, npm downloads, clones

Stage 3: FIRST CONTACT (100 people)
  - Open an issue, ask a question, join chat
  Metric: New issue creators, new discussion participants

Stage 4: FIRST CONTRIBUTION (20 people)
  - Submit a PR, write docs, help in issues
  Metric: First-time contributors per month

Stage 5: REPEAT CONTRIBUTOR (5 people)
  - Multiple contributions, sustained engagement
  Metric: Contributors with 3+ contributions over 3+ months

Stage 6: CORE CONTRIBUTOR (1 person)
  - Regular, significant contributions; trusted reviewer
  Metric: Contributors with commit access or reviewer role

Conversion Rates (typical healthy project):
  Awareness to Interest: 10%
  Interest to First Contact: 10%
  First Contact to First Contribution: 20%
  First Contribution to Repeat: 25%
  Repeat to Core: 20%

Measuring the Funnel

# GitHub API queries for funnel metrics
import requests
from datetime import datetime, timedelta
from collections import Counter

class ContributorFunnel:
    def __init__(self, owner, repo, token):
        self.base_url = "[GitHub repository]".format(owner, repo)
        self.headers = {"Authorization": "token {}".format(token)}
        self.since = (datetime.now() - timedelta(days=90)).isoformat()

    def get_new_issue_creators(self):
        """Stage 3: First contact via issues."""
        issues = self._paginate(
            self.base_url + "/issues",
            params={"since": self.since, "state": "all"}
        )
        creators = set()
        for issue in issues:
            if not issue.get("pull_request"):
                creators.add(issue["user"]["login"])
        return creators

    def get_first_time_contributors(self):
        """Stage 4: First contribution."""
        prs = self._paginate(
            .base_url + ,
            params={: , : }
        )
        first_timers = ()
        all_authors = Counter()
         pr  (prs, key= x: x[]):
            author = pr[][]
            all_authors[author] += 
             all_authors[author] ==   pr.get():
                first_timers.add(author)
         first_timers

     ():
        
        commits = ._paginate(
            .base_url + ,
            params={: .since}
        )
        author_months = {}
         c  commits:
             c.get():
                login = c[][]
                month = c[][][][:]
                author_months.setdefault(login, ()).add(month)

         {a  a, months  author_months.items()
                 (months) >= min_months}

---

Key Metrics Dashboard

Project Velocity

Metric	Formula	Healthy Range	Warning
PR merge time (median)	Time from PR open to merge	< 3 days	> 14 days
Issue response time	Time to first maintainer comment	< 48 hours	> 7 days
Issue close rate	Closed issues / opened issues (monthly)	> 0.8	< 0.5
Release frequency	Releases per quarter	2-6	0 in 6+ months
Commit frequency	Commits per week (excluding bots)	Stable or growing	Declining 3+ months

Community Health

Metric	How to Measure	What It Indicates
Bus factor	Number of contributors for 50% of commits	Knowledge concentration risk
Elephant factor	Number of orgs for 50% of contributions	Organizational diversity
New contributor rate	First-time contributors per month	Community growth
Contributor retention	Percent of contributors active 6 months later	Community stickiness
Responsive maintainers	Percent of issues with response under 48h	Maintainer engagement

Sustainability Indicators

GREEN (healthy):
  - 3+ active maintainers from 2+ organizations
  - New contributors every month
  - Issues and PRs addressed within a week
  - Regular releases (monthly to quarterly)
  - Growing or stable download/install numbers
  - Active communication channels

YELLOW (at risk):
  - 1-2 active maintainers
  - Declining new contributor rate
  - Growing backlog of unaddressed issues
  - Releases slowing down
  - Key maintainer showing signs of burnout

RED (critical):
  - Single maintainer with declining activity
  - No new contributors in 3+ months
  - Security issues unaddressed
  - No releases in 6+ months
  - Maintainer publicly expressing burnout/frustration

---

Measuring with Tools

GrimoireLab (CHAOSS Reference Implementation)

Components:
- Perceval: Data collection from 30+ sources (Git, GitHub, Slack, etc.)
- Elk: Enrichment and storage in Elasticsearch
- Kibiter/Sigils: Kibana dashboards for visualization

Setup:
  docker-compose up  # launches full stack
  Collects data from configured repositories
  Pre-built dashboards for CHAOSS metrics

DIY Dashboard (GitHub API + Grafana)

# docker-compose.yml for simple metrics collection
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: oss_metrics
    volumes:
      - pgdata:/var/lib/postgresql/data

  collector:
    build: ./collector
    environment:
      GITHUB_TOKEN: from-environment
      DATABASE_URL: postgres://postgres@postgres/oss_metrics
    # Runs daily to collect metrics

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - ./grafana/dashboards:/etc/grafana/provisioning/dashboards

-- Example queries for Grafana dashboards

-- Monthly active contributors
SELECT date_trunc('month', authored_date) AS month,
       COUNT(DISTINCT author_login) AS contributors
FROM commits
WHERE authored_date > NOW() - INTERVAL '12 months'
GROUP BY month ORDER BY month;

-- PR merge time trend
SELECT date_trunc('week', merged_at) AS week,
       PERCENTILE_CONT(0.5) WITHIN GROUP (
           ORDER BY EXTRACT(EPOCH FROM merged_at - created_at)/3600
       ) AS median_hours_to_merge
FROM pull_requests
WHERE merged_at IS NOT NULL
  AND merged_at > NOW() - INTERVAL '6 months'
GROUP BY week ORDER BY week;

-- New vs returning contributors
SELECT date_trunc(, first_contribution)  ,
       ()  new_contributors
 (
     author_login,
           (created_at)  first_contribution
     pull_requests
     merged_at  
      author_login
) first_prs
     ;

---

Interpreting Metrics

Common Patterns and What They Mean

Pattern: High star count but few contributors
Diagnosis: Project is useful but hard to contribute to
Action: Improve contributing guide, add "good first issue" labels,
        simplify development setup

Pattern: Many PRs but slow merge times
Diagnosis: Maintainer bottleneck
Action: Add more reviewers, implement PR triage process,
        consider automated merging for trivial changes

Pattern: Declining new contributors but stable users
Diagnosis: Project is mature but may face sustainability risk
Action: Actively recruit contributors, create mentorship programs,
        apply for foundation/corporate sponsorship

Pattern: Many forks but few upstream PRs
Diagnosis: Fork culture -- people modify but don't contribute back
Action: Make contributing easier, engage with active forkers,
        investigate if forks address unmet needs

Pattern: High issue volume, low close rate
Diagnosis: Maintainer overwhelm or unclear issue triage
Action: Implement issue templates, auto-close stale issues,
        recruit issue triage volunteers, clarify scope

Metrics Anti-Patterns

DON'T:
- Optimize for GitHub stars (vanity metric, not health)
- Compare absolute numbers across different-sized projects
- Use metrics to punish or pressure individual contributors
- Ignore qualitative signals (maintainer mood, community tone)
- Measure too many things (pick 5-7 key metrics)

DO:
- Track trends over time, not absolute values
- Combine quantitative metrics with qualitative observation
- Benchmark against your own project's history
- Use metrics to identify where to invest effort
- Share metrics transparently with the community

---

Action Playbook

Improving Contributor Retention

Week 1-2: Welcome and Onboard
  - Auto-welcome first-time contributors (GitHub Action)
  - Assign a mentor/buddy for first PR review
  - Respond to first PR within 24 hours (critical for retention)

Month 1: Deepen Engagement
  - Invite repeat contributors to chat channel
  - Assign them as reviewers for related PRs
  - Recognize contributions in release notes

Month 3: Empower
  - Offer triage permissions
  - Invite to maintainer meetings
  - Create pathways to committer status

Measure: Track 30/60/90-day contributor retention rate
Target: 40% of first-time contributors make a second contribution

Building a Metrics Practice

1. Start simple: Track 3-5 metrics monthly
   - New contributors
   - Median PR merge time
   - Issue response time
   - Active contributors (monthly)
   - Release count

2. Automate collection: Weekly GitHub Action or cron job

3. Review monthly: Brief write-up of trends and actions

4. Share publicly: Monthly community health reports build trust

5. Iterate: Add metrics as questions arise, remove noise

Process

1. Gather information. Ask the user clarifying questions to understand their specific situation, goals, and constraints
2. Analyze context. Review the information provided and identify key factors relevant to oss metrics analyst
3. Develop recommendations. Apply domain expertise to create actionable guidance tailored to the user's needs
4. Present structured output. Deliver findings in the output format below with clear next steps
5. Address follow-ups. Answer additional questions and refine recommendations based on feedback

Output Format

## Oss Metrics Analyst Analysis

### Assessment
[Key findings and observations]

### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]

### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]

Edge Cases

• Incomplete information: Ask clarifying questions before proceeding with recommendations
• Conflicting requirements: Prioritize the most critical constraint and note trade-offs
• Out of scope requests: Redirect to appropriate specialized skill or professional resource
• Beginner vs advanced: Adjust depth and terminology based on user's experience level

Example

Input: "Help me with oss metrics analyst for my current situation"

Output:

Based on your situation, here is a structured approach to oss metrics analyst:

1. Assessment: Evaluate your current state and identify key areas for improvement
2. Strategy: Develop a targeted plan based on best practices
3. Implementation: Execute the plan with specific, measurable steps
4. Review: Monitor progress and adjust as needed