A maintainable dashboard for open source health

When the World Health Organization became the first UN agency to launch an Open Source Programme Office (OSPO), it also inherited a practical problem: how do you measure the health of a growing ecosystem spanning over 100 public repositories? To answer that, GitHub's Social Impact Skills-Based Volunteering program built an open source metrics dashboard, and the project surfaced some useful lessons for any team building similar tooling.

Defining "healthy" before measuring it

The design process started with a question: what does a healthy open source project actually look like? The team used the Linux Foundation's CHAOSS project as a reference point for established community health metrics, then cross-referenced those with what the WHO's OSPO actually wanted to track. The final list was filtered once more against what was realistically computable with available data.

Building a dashboard of this kind brings recurring challenges that shape every architectural decision:

  • Expense: data volume affects both API costs and page load performance.
  • Data storage: reducing dependencies meant finding lightweight ways to persist computed metrics.
  • Rate limits: GitHub API constraints forced a rethink of how much data could be fetched and how often.
  • Maintainability: the tool had to be easy to learn and run for a small team over the long term.

Workflow and architecture

The project was built in two separate applications: a TypeScript backend responsible for data generation, and a Next.js/React frontend render the UI. At build time, a GitHub Actions pipeline handles the heavy lifting:

  • Fetch raw data from GitHub's GraphQL API.
  • Transform and aggregate it into the desired shape.
  • Export the result to a JSON file.
  • Load that JSON into the Next.js static site build, which gets published to GitHub Pages.

That last step is the project's core design choice. Because all data is pre-populated at build time, the resulting site loads fast even for organizations with a few dozen repositories—no server-side queries required on page view.

Collaboration on the project relied on a few practices that kept distributed contributors aligned. GitHub Issues tracked individual work and future ideas; pair programming gave real-time feedback; monthly syncs with the WHO team surfaced feature requests, like a topic filter for showing a subset of repositories to specific maintainers. The dashboard was also built with customization in mind so owners can manage it without engineering help.

Three practices that matter

The project distilled its lessons into three recommendations for open source work generally.

1. Build in the open from day one

Starting public forces you to plan and break work into small, approachable pieces. That helps core contributors focus while newcomers can pick up lower-effort tasks. The repository used linters and formatters to keep code style consistent, which shortens onboarding time. Rulesets protected the main branch from unsolicited pushes.

Working publicly also exposes you to a wider pool of knowledge, and the issue history preserves context for future maintainers. The tradeoff is that everything you commit becomes visible—so it's worth deciding early whether you're comfortable with that level of transparency.

2. Configure for the least technical user

The dashboard's audience included people without a technical background, so configuration was designed around a single YAML file in the repository root. Forking the project, editing that one file, and running it should get you to a working dashboard. A side benefit: because contributors don't modify core code, they can pull upstream changes without creating merge conflicts.

3. Treat community presence as part of the build

Being responsive to issues keeps a project alive—the people asking questions are the ones actually using the tool. Regular releases also signal that the project is maintained. Alongside that, proper project documentation (a clear README, code of conduct, security policy, and support notes) shapes how the community perceives the project's professionalism. And shipping isn't the finish line: blog posts, talks, and demos are what grow an audience for the work.

What's next

The dashboard's own metrics now guide its roadmap. Planned improvements include database support, more control over which data is fetched and displayed, further UI iteration, trend analysis over time, and a review of all dependencies and components. For other teams that want to volunteer engineering time toward similar open source efforts, opportunities are listed on For Good First Issue.