GitHub is the world's most popular place to host versioned code, but fails to surface meaningful data at an organization level.
GitHub organizes code into repositories, and further organizes it into owners.
This story may seem like a great way to capture information, but we're letting the majority of information fall through the cracks. Organizations, particularly Enterprises, don't organize their code like this. Repositories are used for a ton of reasons, all of which we fail to truly capture.
We provide some high level detail into the % of code that is Ruby, or JS, or Swift. We provide some high level detail into activity of a repo. We provide some idea into the most recent repos by ordering the repos by most recent contributions. None of this captures the picture of what a repo really is.
A repo could be a framework, a package, design guidelines, a team's documentation repository, a repo with the sole purpose to capture issues, the main application, an internal application, documentation, and dozens of other possibilities.
A repo may be the most important application in the company (GitHub/GitHub), or it may be critical to the functioning of the company (GitHub/hookshot), it may just be an internal application (GitHub/team), or it may just be docs (GitHub/engineering). We have no idea because none of that is surfaced in any meaningful way in GitHub.
We've solved a lot of this internally, in some way. We have https://catalog.githubapp.com. This application tracks the repository, what it is, what it is used for, where we can find logs, where we can find CI, docs, monitoring, who owns it, and importantly how important is it to the business?
Enterprises want a Service Catalog in GitHub.
GitHub is the only company in the position to meaningfully leverage data, UI, and other technologies to act on this. We are able to:
- Track dependencies and update them
- Scan repositories for security vulnerabilities and report them
- Detect credential leaks
- Detect Language type
- Detect repos using each other (dependency graph)
- CI/CD internally
- and more.
Now imagine we leverage this at the Organization level. We allow users to specify teams who "own" a repo, or a subset of a repo (CODEOWNERS). We allow executive sponsors of repos (directors, etc). We allow other metadata in a .github/* file to specify importance, etc.
We surface this as an aggregation so that a CTO or SVP of engineering can see a snapshot of their organizations code health (perhaps give a code health score, similar to the compatibility score we see in the dependency CI fanout strategy). We surface this so a direct can see their teams code, and the health score for that subset. We surface this so a team can get an overview of what they need to do (security issues across repos, dependencies out of date, etc).
Of course, we can allow an organization to set requirements to influence that score (e.g. all apps that are code must have CI/CD, all apps in Tier 1 importance must have check X enabled, etc).
The level of empowerment of data aggregation would be unparalleled. Furthermore, presenting data in this way would give us an easy avenue into something like Service Communications (e.g. GitHub/GitHub connects to GitHub/Hookshot). Then we can make dependency graphs for an entire org.
It also presents us with a way to provide hosting of documentation, an evolution of the wiki, across an entire org. Giving us a great way to embed search across all repos' docs, with rich abilities for advanced search (docs I own, docs in engineering, docs that HR owns, etc).
I have some more written on the topic of Service/App Catalog/Databases: https://www.notion.so/jnadeau/Service-App-Databases-081f1adccc684bf2b1ae3c0283d281d5
The post-GitHub section in this issue also explains some of these thoughts.