skip to content

Microsoft has a strong open source program that encourages contribution, respects license obligations, allows engineers to use open source with ease, work in the open, release projects, and be secure.

Today, it’s not uncommon that we use over 150,000 open source components per month. Relentless automation, engineering system innovation, and making it easy for our developers to "fall into the pit of success" have been key to using open source at enterprise-scale.

Here are just a few of the ways that we've built a strong open source program. We can't wait to share even more to help you be successful with open source, too.

The Microsoft open source program is managed by the Open Source Programs Office in partnership with expert teams across Microsoft. A community of open source experts, open source leaders, and others help curate guidance and policy.

One Engineering System (1ES)

The 1ES team at Microsoft has made using, releasing and contributing to open source an easy, efficient, native part of the engineering experience.

Building on a foundation of eliminate (reducing complex and dated policies for the modern engineering era), automate (detecting open source use, automated policy and decision guides, legal alerts and security workflows), and delegate (letting business groups make decisions aligned with their priorities and goals), the open source program has scaled.

  • Built into the engineering system: Powered by GitHub and Azure Pipelines, and internal hyperscale CloudBuild, CloudTest, and policy systems, many tasks as simple as maintaining an inventory of the open source used in builds and products is automatic.
  • Using GitHub Enterprise Cloud: Over 35,000 engineers at Microsoft are using GitHub Enterprise Cloud to host and release official Microsoft open source projects, samples, and documentation, building communities and connecting directly with technologists and Microsoft customers right on GitHub, working in the open.
  • XYZ: x

Expert support & resources

A coalition of teams, experts, and friendly resources are available to make sure that everyone at Microsoft understands how to use open source.

  • Easy, crisp guidance for engineers: Comprehensive reference material for everyone at Microsoft to refer to helps to share knowledge and reduce confusion. Checklists, policies and advanced guides have been prepared by Subject Matter Experts, open source attorneys, and curated by engineers, to make learning about using open source easy and efficient.

    If you work at Microsoft, you can authenticate and find these resources at
  • Open Source Standards and Legal Team: Expert attorneys and program managers with decades of open source experience from across the industry make up the legal team that crafts policies, guidance, and inform their clients regarding all their licensing and open community needs. Every employee at Microsoft has access to an open source attorney dedicated to their organization and familiar with their business goals and unique needs.
  • Open Source Champs: Internal e-mail discussion lists and Microsoft Teams channels make it easy and straightforward to connect with open source maintainers and experts to get answers.

    The Open Source Champs come from teams across Microsoft and are able to help advise their team and help share knowledge.
  • Business and Legal review process: Some open source activities at the company, depending on use case, license, or other conditions, may automatically trigger a straightforward business and legal review process.

    An open source review takes the form of a standard engineering work item and presents reviewers with a contextual look at the business goals, specific use scenario, and other aspects, to help make the right decisions for some scenarios.
  • Open Source Executive Council: Essentially the board of directors for the open source program, the executive council consists of leaders from across Microsoft. The council helps to guide the program, highlight opportunities, and provide a central place for decisions regarding open source.

OpenChain 2.0 conformance

Trust is key to open source. Developers should be able to trust users to respect their licensing choices. And when you receive software, you should be able to trust that the open source licenses were followed.

The OpenChain Project plays an important role in building trust by setting standards that define how to operate a high-quality open source compliance program. It means that when you receive open source from a company that follows the OpenChain standard, you can be assured that the code went through a rigorous license compliance process. You can trust it.

We announced that Microsoft is OpenChain 2.0-conformant in December 2019 and continue to keep the program up-to-date with ongoing training and other ongoing aspects of conformance.

At Microsoft, we make it easy for engineers to easily use open source software, while respecting the rights of open source licenses and contributors, and building secure solutions.

Open source use guidance

This is a summarized, distilled look at general open source contribution requirements at Microsoft.

Using open source in Microsoft is encouraged. Building on the efforts of others allows us to create meaningful value for our customers faster and engage with new ecosystems and user-bases in a natural way.

Take the following steps to use an open source component at Microsoft:

  • Register All Open Source: Following the open source compliance policy, all open source components must be registered. You can do this two ways:
    • One Engineering System automatically registers most types of open source. Open source detectors are run and will handle the registration of open source components. Legal and security alerts will be raised with follow-up actions if there is additional work required, such as meeting legal obligations, posting to the third-party disclosures site, addressing a security issue, or if a commercial or unknown license is present.
    • For repos using certain types of open source, a Manual Registration approach or file can be used in lieu of detectors. Boutique engineering systems will need to refer to the non-standard build environments content.
  • Keep Open Source Separate: Follow Microsoft's Intellectual Property Separation Policy to keep the open source code separate from Microsoft code in your code tree.
  • Distribution Requirements: If you plan on distributing the open source component in a Microsoft Product or Service, you must take additional steps, as guided by legal alerts, that might include:
    • NOTICE generation. A NOTICE file is required. The automated NOTICE tool can create the file to distribute it with the product.
    • Make Source Code Available. For components under certain licenses, you must make source code available on Microsoft's Third-Party Source Code Disclosures site. The extent of the source code disclosure will depend on the type of license.
    • Enhanced License Compliance. Some products require additional license compliance work.
  • Code Signing: Ensure you are complying with the code signing requirements.
  • Open Source That Does Not Require Registration: You do not need to register software you install as an end user that is based on open source, e.g. Microsoft Edge web browser, Mozilla Firefox, Microsoft Visual Studio Code, Atom.

We encourage our employees to contribute to open source communities. Data shows that tens of thousands of our engineers are active on GitHub regularly, many contributing to great open source projects that help everyone.

Contributing to open source

This is a summarized, distilled look at general open source contribution requirements at Microsoft.

Contributing back to the projects we use is a key element of the open source process. Contributing our own improvements enhances the value we derive from the project and drives the project forward. Microsoft open source contribution policy varies depending on the size and purpose of the contribution.

  • Small changes: If your contribution meets the small contribution exception (like a bug fix), just create a fork, make the fix, and submit a pull request. If making the pull request on GitHub, you can create the fork in your personal GitHub account, rather than an official Microsoft organization account.

    While the small contribution policy outlines all the specifics, we've made it easy to contribute to a number of great projects: small contributions can be made if there is no Contributor License Agreement (CLA), or, there is a list of specific CLAs that can be signed, such as those for the Apache Foundation, Eclipse Foundation, Linux Foundation, Google open source projects, the .NET Foundation, Python Software Foundation, and the Unicode Consortium.
  • Larger changes: If the contribution is larger get your contribution reviewed and approved. If the contribution is to a project on GitHub, it can come from your individual GitHub account (though do identify yourself as a Microsoft employee) or in some cases as more of a hard fork from an official Microsoft organization, and make the pull request from there.
    • Scoping Your Request. When you fill out the contribution request, describe the full extent of the functionality you intend to contribute with your community engagement. So long as you stay within this description, the great news is that you do not have to file a registration for each individual contribution. However, if subsequent contributions go beyond the initial scope, you need to do another Contribution request.
    • Contributor License Agreements. As part of the review process, you will be asked whether the project requires a Contributor License Agreement. The project's contributing guide will typically have this information.
  • Outside of Work Contributions: If you are contributing to projects on your own time, this work is covered by your employment agreement and the Microsoft moonlighting policy. Read the policy and talk with your management to determine whether your contributions meet the policy.
  • Meet Community On Its Own Terms: Note that different open source communities take contributions in different ways. Before firing off a pull request, investigate how best to engage the community you will be contributing back to.
  • Fork Nicely: Always try to contribute to a community instead of hard forking. Review internal guidelines and training before forking into a Microsoft org.

Working in the open

Teams at Microsoft are encouraged to work in the open and are provided with straightforward guidance on when and how to release code to the world.


Release approvals

text here