The opensource.microsoft.com repository is a static Next.js site with strict contribution rules

A static site about a programme, run by two teams

The opensource.microsoft.com web site is described as a simple, factual web site sharing information about Microsoft's open source program, the open source ecosystem that we support, and opportunities to get involved in projects and learn more.

The architecture is the interesting part for anyone reading the code. Most of the content is static, and Next.js is now used to generate that modern static site, ported from an old Jekyll site. The rendered site is retrieved at runtime by a separate site hosting solution.

So the repository is a static site generator configuration, not a web application. The output is a set of files that a hosting platform serves, and the reason the readme distinguishes the static part from the runtime is that anything dynamic lives in the hosting layer rather than in here.

The provenance is stated too. The site was created by the Microsoft Open Source Programs Office, the OSPO, in partnership with Microsoft's One Engineering System team, and it launched in August 2020, replacing an antiquated prior site.

The primary language is TypeScript, the licence is MIT, and the last push was on 2026-10-01. The package version in the manifest is 2.0.0, and the repository has no GitHub releases, so the version line lives in the manifest and in the deployment rather than in tags.

What the site contains, and what it deliberately does not

The primary navigation is five sections, and the readme lists them in order: the homepage overview, get involved, projects, ecosystem, and our program.

The rest of the content is a short list of satellites. Jobs is an external link rather than a page on the site. The blog is a separate site hosted at /blog via the front door, which is a common pattern for a static site that wants to keep an existing publishing platform. There is the code of conduct text, a community resources section, a thank you page about the open source powering the project, an OpenAtMicrosoft X account, and the link to this repository itself.

What is missing is as informative as what is there. There is no documentation section, no tutorials, no per project deep pages in the site itself, and no news archive.

That is consistent with the stated role. The site explains the programme and points at the projects, and it deliberately does not try to be the place where the technical content lives.

The internal structure of the repository mirrors that. There are src/ and public/ for the application, content.json and markdown directories for the content, with _projects/ for the project entries, _community/ for the community material and _fossfund/ for the FOSS fund content. There is also an .old-jekyll-site/ directory, which is the previous site left in the tree, and that is worth a look if you want to see how the port was done.

The contribution policy is the thing to read first

The contributing section is unusually explicit, and it is the part a prospective contributor needs most.

The project expects that limited updates and contributions to the site will be made by Microsoft teams. It does not currently have plans to add drastically different sections to the site or to be the source of truth for blog posts or other content. The project is able to accept some coordinated contributions or suggestions, but requests coordination in issues before embarking on new functionality, as the site has a set of requirements to meet such as being WCAG 2.1 accessible, and deploying to Microsoft's cloud.

And then the sentence that sets expectations honestly. As a public-facing site hosted at microsoft.com, we may not be able to accept general contributions to this site, so your pull request may be closed and not merged, even if it's great, and we may not be able to provide complete context for any such decision.

The contribution scenarios section says the same thing from the other side. Please make sure to communicate any contribution ideas as an issue before starting a pull request, and the project is happy that this site is open source because a site about open source should be open source.

So the model is open source with a gate. The code is public and the licence is MIT, but the maintainers keep the content model, the accessibility requirement and the deployment target under their control. A contributor who reads the issue-first rule as a formality will have a bad time.

CLA, code of conduct and trademarks

Three administrative sections complete the contribution picture, and one of them has an operational consequence for your workflow.

The project has adopted the Microsoft Open Source Code of Conduct, with a link to the FAQ and an address, [email protected], for questions.

The CLA section explains the Contributor License Agreement. Most contributions require you to agree to a CLA declaring that you have the right to, and actually do, grant the rights to use your contribution. The interesting part is the automation: when you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the pull request appropriately with a status check and a comment, and you follow the instructions the bot gives you. You only need to do this once across all repos using the CLA.

That is a better design than a human chasing signatures, and it is worth knowing that a CLA gate is the first thing a pull request will meet.

The Trademarks section is the one that catches people out when they fork. The project may contain trademarks or logos for projects, products or services, authorised use of Microsoft trademarks or logos is subject to and must follow the Microsoft Trademark and Brand Guidelines, and use of Microsoft trademarks or logos in modified versions must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third party's policies.

So the MIT licence covers the code, and the brand rules cover the names and logos, and a fork that keeps the Microsoft name in the header needs thought.

Telemetry is off unless the build environment says otherwise

The Telemetry section describes a build-time switch, which is a rare and rather elegant way to handle analytics.

By default, this project does not include telemetry, however the GitHub Actions may generate the production version of the site without modification. When the Jekyll build environment is set to Microsoft's production environment name, opensource.microsoft.com, Microsoft's standard cookie compliance and analytics code to connect with Application Insights is included in the site.

So the rule is a single environment variable. A fork that builds with the default environment ships a site with no analytics at all, and one that sets the environment name to the production value ships the real thing with the real tracking, whether or not the person deploying it intended that.

The section then spells out the data collection terms, that the software may collect information about you and your use of the software and send it to Microsoft, that Microsoft may use it to provide services and improve its products, and that you may turn off the telemetry as described in the repository. It also notes that there are features in the software that may enable you and Microsoft to collect data from users of your applications, in which case you must comply with applicable law including providing appropriate notices to users together with a copy of Microsoft's privacy statement, and that your use of the software operates as your consent.

For a fork, the practical advice is to leave the production environment name unset, and to read the section rather than assume.

Accessibility is checked in CI with axe

The Development section is short, and the second half of it is the most interesting.

The first part is the usual pair.

npm install
npm run dev

And then the accessibility checks for the primary site pages.

npm run a11y:install
npm run a11y

The description explains the mechanics. The accessibility check builds the exported site, serves the generated out/ folder locally, and runs axe-based checks in Chromium against the main routes. In CI, the workflow reuses the existing build output instead of rebuilding.

That is a well built arrangement, and the reason to look at it closely is that it is unusual. Accessibility is usually a manual checklist or a lint rule, and both miss the things that only appear in a rendered page. Serving the actual export and running axe against the real routes tests the output that users get, including the styling, which is where contrast and focus problems live.

The reuse of the build output in CI is the detail that makes it affordable. Rebuilding the site for every accessibility run would double the pipeline, and a check that is expensive gets skipped.

The tooling behind it is visible in the manifest, with @playwright/test and @axe-core/playwright as dev dependencies and a dedicated playwright.a11y.config.ts at the root, and the axe checks run through the Playwright test runner rather than as a separate tool.

The Dockerfile serves the export with nginx

The Dockerfile is available to host a local nginx version of the static site, although dynamic site features are not available when running local.

The build stage is Microsoft's own Azure Linux nodejs base image.

ARG IMAGE_NAME=mcr.microsoft.com/azurelinux/base/nodejs:20
FROM $IMAGE_NAME AS build

The runtime stage is the bare Azure Linux core image with nginx installed on it, and the built output is copied into the web root.

COPY --from=build /build/out .
EXPOSE 80

The rest of the file is the operational part. The permissions on the web root are set, the health check curls the root of the container every thirty seconds with a three second timeout and a forty second start period and three retries, and the container runs nginx in the foreground with the daemon off flag.

Choosing nginx rather than a Node server for the runtime stage is the right call for a static export, because the image that ships is a web server and a directory of files with no Node runtime in it at all. The start period on the health check is the one number that reflects the real behaviour, since it allows the container to come up without failing checks while nginx binds.

The build context copies the whole repository in and runs npm install and npm run build, so the image build does the install rather than relying on a package cache layer, which is a small cost for a build that is not often repeated.

The stack, and the shape of the content

The package manifest describes a fairly conventional modern Next.js application, and the dependencies explain the content model.

Next is at 16.3.6 with React 19, and the styling comes from the Primer family, the @primer/css package with octicons-react, primitives and view-components, which is GitHub's design system. That is a sensible choice for a site about a programme that is a close partner of the GitHub community.

The content handling is where gray-matter comes in, and the data fetching uses axios and @tanstack/react-query, so the site pulls some of its data at build time rather than only reading static files. The browserslist is set to the last 2 versions, and the tooling is eslint-config-next, postcss, sass and a pinned TypeScript.

The layout of the repository is the other clue. There is next.config.ts, tsconfig.json, next-env.d.ts, the src/ and public/ directories, the tests/ directory, and a content.json next to the underscore-prefixed content directories.

The underscore prefix on _projects, _community and _fossfund is a convention that keeps content directories out of the routing while keeping them obvious to a human, and combined with content.json it suggests a hybrid model where some pages are generated from files and some are described in a manifest.

Overall it is a well built and unusually honestly documented static site, and the documentation about who may change it is the part most worth reading before you open a pull request.

Editorial conclusion

Adopt this repository as a reference if you are building a static programme site on Next.js and want the accessibility and content structure to copy. Do not expect an open contribution model, because the project asks for an issue before any pull request and states that contributions may be closed even when they are good. Verify first that the content you want to add fits the existing sections, since the maintainers say there are no plans to add drastically different sections, and check the telemetry section before deploying with the production build environment name, because that is what pulls in the analytics code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/opensource.microsoft.com on GitHub
4. Project website
5. README