How GitHub Gave Every Repository a Durable Owner

A software company with more than 14,000 internal repositories discovered that fewer than half had a clear owner. Here is how the team turned a sprawling asset-management blind spot into a fully owned, queryable code inventory in under 45 days.

Large engineering organizations accumulate code faster than they can keep track of it. Forks drift, prototypes survive long after the project that spawned them ended, and the line between “production service” and “someone’s old experiment” blurs. GitHub, the largest code-hosting platform on the planet, faced exactly this problem inside its own primary internal organization.

From service catalog to repository-first

For years GitHub tracked ownership the way most mature teams do: through an internal Service Catalog. Each entry mapped a deployed service to its repository, owning team, executive sponsor, and support channel. The catalog worked well for production systems. It did nothing for the thousands of repositories that backed no running service at all.

By early 2025 more than 11,000 non-archived repositories carried no reliable ownership metadata. That is a security and operational liability: if a vulnerability is disclosed in a forgotten library, nobody knows who should respond.

The mechanism: custom properties, enforced by a GitHub App

The team moved the ownership model from the service level down to the repository level, using a native GitHub feature that had been largely invisible to most users: Custom Properties. Custom Properties let an organization define structured fields on every repository and make them searchable across the entire org.

Ownership was categorized into three clean types:

Three ownership tiers. A Service Catalog entry for production services with a named team; a Team tag for shared tooling, docs, and scaffolding; and a Hubber Handle (an individual GitHub account) for personal or prototype repositories. The rules are simple: every active repository picks exactly one tier, and the responsible party is unambiguous.

To enforce the model at scale the team built a GitHub App backed by a small Kubernetes deployment that watches repository events, validates the property values, and nudges (or escalates) when ownership is missing or stale. What previously required a manual spreadsheet review became an automated, always-current constraint.

Why it works in under 45 days

The result was a complete asset map: 11,000 orphaned repositories reclassified into owned, team, or personal buckets. The key insight is architectural, not cultural — you do not need a policy committee to solve ownership; you need a schema the platform can enforce. Custom Properties gave GitHub a place to put that schema, and a lightweight automation layer made it self-sustaining.

Knowledge takeaway: The platform feature is Custom Properties — structured, org-wide metadata on every repository; the enforcement is a small GitHub App, not a process document; any team can replicate the three-tier model (service / team / individual) to eliminate “orphan code” in weeks rather than quarters.