# Microsoft's Open Source Management Portal: a company view of GitHub

> The Open Source Management Portal is the backend behind Microsoft's open source engineering experience, with 70,000 engineers using a version of it. It links GitHub accounts to corporate identities, intercepts repository creation to inject compliance, and exposes permissions and cross-organization search that GitHub's own interface cannot show. The readme is candid that it is a partial reference implementation and does not entirely build today.

**microsoft/opensource-management-portal** — Microsoft's monolithic, opinionated Open Source Management Portal enabling enterprise scale self-service powered by the GitHub API 🏔🧑‍💻🧰

- Repository: https://github.com/microsoft/opensource-management-portal
- Stars: 534 · Forks: 140
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-opensource-management-portal

## What the portal is for

The Open Source Management Portal is described in the repository description as Microsoft's monolithic, opinionated Open Source Management Portal, enabling enterprise scale self-service powered by the GitHub API.

The readme explains the intent more carefully. This application represents the home for open source engineering experiences at Microsoft. As a backend application it manages source of truth for many types of corporate open source metadata, historical intent of repos and projects, hosts a rich front-end, and also a set of APIs used by partner teams.

Then comes the reason it exists at all, and it is a candid one. While we prefer native GitHub experiences, when it comes to displaying certain info and being more transparent about permissions and metadata, especially on GitHub, which has no extensible user interface, we end up using and driving people to this Open Source Management Portal to get the information they need.

So the justification is a gap in GitHub rather than a dissatisfaction with it. GitHub is where the code lives, but GitHub cannot show you the corporate metadata, the approval history, or the cross-organization view that a company's own governance model needs. The portal is the layer that answers those questions and, where it can, does the work of driving GitHub on the engineer's behalf.

The scale figure is 70,000 engineers using a version of this portal as part of their open source engineering experience. The word version is doing careful work in that sentence, and the readme immediately follows it with the caveats: Microsoft does have a set of company-specific extensions, including a separate React frontend client, that are not currently part of this repository. And, and yup, if we were to start over today, we'd probably make this a Next.js-or-similar project.

That last admission is worth reading as guidance rather than as an apology. A reviewer is being told that the frontend architecture would be different with hindsight, which tells you something about the age and shape of the code without needing to inspect it.

## The capability list, and what each one implies

The core capabilities list is eleven items, and they fall into a few clear groups.

The identity and access group comes first. Linking GitHub accounts for enterprise use, and a people inventory to help people connect GitHub public logins with corporate identities. That second one is the load-bearing piece for everything else, because it is what lets the portal answer questions about a repository that span both sides of the corporate boundary.

The self-service group is next. Self-service GitHub organization joining for engineers, creating and managing GitHub open source repositories, and team join requests and approvals with context, which the readme describes as building beyond the GitHub experience.

The governance group is the part that would be hardest to build from scratch. Intercepting forks and new repositories to inject compliance and approval processes. Disable and enable experiences for GitHub repositories. And sudo capabilities for repos, teams and organizations to remove persistent broad ownership and admin permissions.

That last one is the most interesting item on the list. Broad admin permissions on a repository accumulate, and removing them by hand at enterprise scale is hopeless, so the portal treats the cleanup as a first-class operation with the authority to do it.

The transparency group is the one the readme leads with in the introduction: displaying transparent information, metrics and company-specific data about the GitHub open source presence around permissions, access, metadata, intent, and especially cross-organization views and search indexes.

Then there are the platform capabilities. Hosting APIs to create repos, for large-scale orgs to access link data, and reports. And background jobs to maintain eventual consistency, run tasks, gather metrics and prepare OKRs.

The combination of sudo, interception and automated offboarding when people take on new opportunities is what makes this a governance system rather than a directory. Whether that is a good idea depends entirely on the company behind it, and the readme's stated design principle is the opposite of a typical admin console: the management portal is designed to be fast, efficient, and get out of the way of engineers to get their important work done, with an emphasis on relentless automation and delegation.

## Consistency, and the split between reads and writes

There is a sentence in the readme that tells you how to model this system, and it is easy to skim past.

Most of the experience is eventually consistent; however, operational actions such as joining teams, orgs, sudo operations, etc., are fully consistent at the time they are requested.

That is a deliberate two-tier design. The read paths, the dashboards, the metrics, the cross-organization search and the background job outputs, are eventually consistent, because they are derived views over state that lives in GitHub and change constantly. The write paths, the actions a person takes, are strongly consistent at the moment they happen, because a person who clicks join and is then told the system does not know about it yet will conclude the product is broken.

The distinction matters for anyone building on top of it. A read that has just changed a repository in GitHub may not reflect immediately. An action that has just been taken is immediately reflected. And the two kinds of operation therefore have different failure characteristics and different UI requirements.

The background job list explains what fills the eventually consistent half: maintaining eventual consistency, running tasks, gathering metrics, and preparing OKRs. Those are not background noise, they are the mechanism that produces the reporting layer, and they are also where the load and latency characteristics live.

The other architectural choice visible in the code is a split between the backend and a separate frontend project. The readme says the company-specific extensions include a separate React frontend client that is not currently part of this repository, and the package.json scripts confirm the frontend lives in its own directory with its own build step, since build:frontend runs the frontend build and build:all runs both.

So the repository is the backend plus a frontend sub-project, and the internal Microsoft variant has a different React client on top of the same APIs. That is what the partner teams are consuming.

## Running it, from the compose file and the Dockerfile

The docker-compose file shows the runtime shape, and it is a conventional three-service stack.

```yaml
services:
  portal:
    image: opensource-portal
    build: .
    ports:
      - '3000:3000'
    networks:
      - portal
    env_file:
      - .secrets.env
      - .docker.env
    volumes:
      - '${PWD}/env-orgs.json:/usr/src/env-orgs.json'
    depends_on:
      - portal-cache
      - portal-db

  portal-cache:
    image: redis
    command: redis-server --protected-mode no
    networks:
      - portal

  portal-db:
    image: postgres
    networks:
      - portal
    volumes:
      - portal_postgres_data:/var/lib/postgresql/data
      - ./data/pg.sql:/docker-entrypoint-initdb.d/pg.sql
    environment:
      POSTGRES_DB: portal-repos
      POSTGRES_USER: portal
      POSTGRES_PASSWORD: latrop
```

The portal service reads two environment files, one for secrets and one for local configuration, and mounts an env-orgs.json file into the container. That last file has an example in the repository, env-orgs.json.example, which suggests it holds per-organisation configuration that changes per deployment rather than being baked in.

The database service initialises itself from a SQL file at ./data/pg.sql through the standard Postgres entrypoint mechanism, which is how the schema gets created on a fresh volume. The cache service runs Redis with protected mode off, which is fine inside the compose network and would not be something to copy into a production configuration.

The Dockerfile is a three-stage build on Microsoft's Azure Linux base image, and it is careful about secrets. The npm configuration is mounted as a build secret with the mount=type=secret syntax for both the backend and the frontend install steps, and the .npmrc is deleted after each use. The dependency install uses npm ci, so the lockfile is authoritative.

Between the stages the build prunes dev dependencies and moves node_modules aside, and the final stage copies the production modules, the built assets, the data directory, the config and the views. The result runs on port 3000 with IS_DOCKER set, which is presumably how the application knows it is containerised.

## The repository layout, and the maintenance scripts

The top level of the repository is large and organised by concern rather than by layer.

There is an api/ directory for the hosted APIs, routes/ for the HTTP surface, business/ for domain logic, features/ for feature modules, lib/ for shared utilities, middleware/ for request middleware, and interfaces/ for abstractions. There is views/ for the server-rendered templates and default-assets-package/ for the static assets that ship with the open source build. There is jobs/ plus a job.ts at the root, and a scripts/ directory.

The configuration files at the root show how the project expects to be run. There is .local.env and .docker.env for local and container environments, .secrets.env.example for the secrets template, and env-orgs.json.example for organisation configuration. There are two tsconfig files, tsconfig.json and tsconfig.oss.json, and the package.json has a separate build:oss script that compiles against the second one. That is the open source build path, and the Dockerfile comment says the open source project build needs the site assets sub-project to be built too.

The npm scripts are the clearest statement of the engineering practices. There is find-deadcode using ts-prune and find-circular-dependencies using madge, which are the kind of scripts a large TypeScript codebase accumulates to stay navigable. The lint chain covers JavaScript with eslint, JSON, Markdown with markdownlint-cli2, and spelling with cspell, with a .cspell.json at the root.

There is a fix script that chains the eslint, markdown and prettier fixes together, and a husky prepare hook so the commit hooks install themselves on npm install.

The package.json version is 7.1.0 and the package is marked private, with the author as Microsoft Corporation and the MIT licence. The keywords and tags are github, management, organization, node.

The remaining top level files are the standard ones, plus a SECURITY.md and a SUPPORT.md, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md that describes the CLA process with a bot that decorates pull requests automatically.

## Conclusion

Adopt this repository as a reference if you are building corporate governance on top of GitHub, because it shows what a permission model, an approval flow and an eventual-consistency job system look like when built at enterprise scale. Do not adopt it as a product to run, because the readme states plainly that it is a partial reference implementation and does not entirely build today, and the company-specific extensions are not included. Before you commit, read the note about the missing frontend and the extra tsconfig.oss.json build, and plan for the eventual-consistency model rather than assuming reads are immediately current.

## FAQ

### What is the Microsoft Open Source Management Portal?

It is a backend application and rich front end that manages source of truth for corporate open source metadata, historical intent of repos and projects, and hosts APIs used by partner teams. It exists because GitHub has no extensible user interface, so certain information about permissions and metadata has to be surfaced elsewhere. The readme says 70,000 engineers use a version of it.

### Is the Open Source Management Portal ready to run?

Not as-is. The readme carries a 2025 note that this project does not entirely build today and is a partial reference implementation for example purposes only. It also says the company-specific extensions, including a separate React frontend client, are not currently part of the repository, and that if they were to start over today they would probably make it a Next.js-or-similar project.

### What consistency model does the Open Source Management Portal use?

Two tiers. Most of the experience is eventually consistent, covering the read paths, metrics and cross-organization views. Operational actions such as joining teams and organisations and sudo operations are fully consistent at the time they are requested, so a person who takes an action gets an immediate answer rather than an eventually correct one.

### What can the Open Source Management Portal do that GitHub cannot?

It links GitHub accounts to corporate identities and keeps a people inventory of public logins against corporate identity, intercepts forks and new repositories to inject compliance and approval processes, offers sudo capabilities to remove persistent broad ownership and admin permissions, provides disable and enable experiences for repositories, and exposes cross-organization views and search indexes alongside metrics.

### How is the Open Source Management Portal deployed?

The compose file runs three services on one network: the portal on port 3000 built from the repository and reading .secrets.env and .docker.env, a Redis cache, and a Postgres database initialised from a SQL file with a named volume for its data. The Dockerfile is a three-stage build on the Azure Linux base image that mounts the npm configuration as a build secret and prunes dev dependencies before the runtime stage.

## Sources

- [Issues](https://github.com/microsoft/opensource-management-portal/issues)
- [License: MIT](https://github.com/microsoft/opensource-management-portal/blob/main/LICENSE)
- [microsoft/opensource-management-portal on GitHub](https://github.com/microsoft/opensource-management-portal)
- [README](https://github.com/microsoft/opensource-management-portal/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-opensource-management-portal