GitGenius
Organization Methodology

Organizations with a page, by kind

Companies are shown as “Owned by”; foundations, communities and research groups as “Hosted by”.

What we measure from

Everything here is computed from the GitGenius catalogue: every public GitHub repository with more than 3,000 stars, plus others added from trending lists, on request, and from the pinned repositories of the organizations in our registry. It is a large slice of GitHub, not all of it. A count on an organization page describes that organization's footprint in the catalogue.

The organization registry

The registry is a hand-maintained list of companies, foundations, communities and research groups, each mapped to the GitHub organizations it owns. Red Hat, for example, owns repositories under several GitHub organizations, and all of them are listed on its page so you can see exactly what we mapped.

• Subsidiaries and member projects keep their own entry with a parent and, for acquisitions, the date the ownership began (“Part of IBM since 2019-07-09”). A parent's page shows its own count and, separately, the count including subsidiaries. The two are never silently added together.
• Personal accounts are never attributed to an employer. A repository under an individual's own GitHub account is not counted for their company, whatever their profile says.

Ownership counts

A repository belongs to an organization when it lives under one of that organization's mapped GitHub organizations. Nothing else is used: no keyword matching, no guessing from descriptions. That makes the count exact for what it covers, and short of the real total in two ways:

• the organization owns repositories that are not in the catalogue, and
• it owns GitHub organizations we have not mapped yet.

That is why each page says “at least” and lists the GitHub organizations it is based on. The categories on an organization page (“Mostly: Kubernetes 48”) use the GitGenius taxonomy and count the same repositories, so they carry the same limits. A category page lists an organization when that category is among the organization's five largest and it owns at least two repositories there.

Which organizations get a page

• An organization gets a page when it owns at least 5 catalogued repositories, or when its people appear in the maintainer activity of at least one project it does not own (see below).
• Pages for organizations that own at least 8 catalogued repositories are submitted to search engines. The rest are reachable by link but not submitted.
• Organizations below both thresholds stay in the registry and their repositories still count toward a parent's total, but they have no page.

These decisions are made from the measured counts, which are rebuilt every four hours, not by hand.

If you would like an organization added to the registry immediately, please contact us.

Maintainer activity

People who did triage or write work on a repository's issues and pull requests in the last 12 months. Rebuilt weekly.

What counts

Only GitHub events that require triage or write permission on the repository: unlabeled, assigned, unassigned, milestoned, demilestoned, locked, unlocked. Someone who removes a label, assigns an issue, sets a milestone or locks a thread has been given that permission by the project.

What does not count, and why

• Comments, mentions, references and subscriptions. Anyone can do these, so they measure participation, not maintenance.
• Closing an issue. The author of an issue can close their own, so it implies no permission.
• Adding a label and renaming an issue. They look like triage, but GitHub issue forms apply labels when an issue is opened and record the issue's author as the one who added them, and authors can rename their own issues. Counting them turned bug reporters into “maintainers” on projects with issue templates.
• Commits and code review. They are not in the data this is built from. A project maintained mostly through code review will show fewer people than do the work.
• Bots. Accounts ending in [bot] and a maintained list of automation accounts are excluded.

Compare a project with itself, not with another project

The headcount depends on how a project runs. Where a bot performs label and assignment changes on a maintainer's command, the humans behind it never appear. Where contributors are allowed to assign themselves, people who maintain nothing do. Both effects are invisible in the number, so two projects' headcounts are not comparable. A project's headcount over time is meaningful as long as its workflow stays the same.

Who works where

Where the Maintainer activity section names organizations, the employer comes from the company field on each person's public GitHub profile. It is self-reported: we do not verify it, many people leave it blank, and some leave it out of date. The text is matched against the names in our registry. A string that could mean two organizations (“IBM / Red Hat”) is not matched to either.

Three denominators, two published

An illustration, with made-up numbers

The page says “at least 40% of the project's 60 maintainers work at Example Corp. 36 say where they work, and 24 of those are Example Corp.” It never says “Example Corp: 100%”, which is what dividing by the matched group would give. The 40% is a true floor: those 24 people are counted, and some of the 24 who did not answer, or the 12 whose answer we could not match, may work there too.

People who fill in an employer are likelier to have one to name, so independent maintainers, hobbyists and academics are the ones most often missing from the answered group. That is another reason the floor leads.

Minimum group size

An organization is named on a project only when at least 5 of its people did maintainer work there. Below that, a count is both too small to mean much and too close to identifying individuals. The organization that owns the repository is not ranked in its own list (“Microsoft maintains a Microsoft repository” says nothing); its people are mentioned in a separate sentence.

What is never published

• No list of people. Every figure is a count. There is no page, file or API that returns which individuals work for an organization or maintain a project, and the indices behind these pages do not store a login, name or email at all.
• Nothing about what people star, watch or follow. Those signals are not used for organizations in any form, not even aggregated.
• Ownership never comes from people. Which repositories an organization owns is decided by GitHub organization, never by who works there.

What cannot be bought

No organization pays to appear, and none can pay to change which repositories are listed, how they rank, or what the numbers say. Organizations that do not work with us get the same page as any that do. If paid placements are ever offered, they will be marked “Sponsored” where they appear and will not affect any figure described here.

Corrections and removal

The registry will have gaps and mistakes: a GitHub organization we have not mapped, a parent that changed, an employer name we do not recognise. If you know of one, tell us. Every organization page lists the GitHub organizations it is based on, so a missing one is easy to spot.

If you do not want to be counted toward an employer, clear or change the company field on your GitHub profile. The next time we refresh your profile, the following weekly rebuild leaves you out of that organization's counts. Nothing about you is stored in these figures beyond the count you contributed to, so there is nothing else to delete.