Culture / Open Source / Contributed

Microsoft: 5 Ways to Make Open Source a Reality at Your Company

21 Jul 2021 9:48am, by

Stormy Peters
Stormy Peters is Director of the Open Source Programs Office at Microsoft. She works with people and teams across Microsoft to help make sure Microsoft uses and contributes to open source software in a way that makes it possible for the world to achieve more through open source software. Before joining Microsoft, Stormy held leadership positions in open source and developer roles at Red Hat where she was head of the Community Leads, the Cloud Foundry Foundation where she was VP of Developer Relations and Mozilla where she led Developer Relations. Previously, she served as executive director of the GNOME Foundation and at OpenLogic where she set up their OpenLogic Expert Community. Stormy graduated from Rice University with a B.A. in Computer Science.

Open source has become critical to nearly every company’s technology strategy and open source usage among developers continues to grow across every industry. There are now over 56 million developers on GitHub and open source project creation jumped 40% YoY1. Using open source in the development process increases time to market, reduces the cost of ownership, and improves software quality.

While open source is here to stay, many companies grapple with how to best enable their employees to use open source safely, provide secure solutions to customers, and effectively contribute to open source software. There is a balance companies need to strike between setting open source policies while also maintaining employee empowerment and autonomy.

At Microsoft, we’ve made a significant shift over the last several years to enable our developers to use open source software seamlessly in their regular development cycle. This was not quick or easy and resulted from both top-down and bottom-up culture change.

Today, our open source efforts are centered in our Open Source Programs Office (OSPO). Many companies today are looking to set up and establish OSPOs and we wanted to share some of the learnings and best practices we’ve had in our OSPO journey so we can all continue to learn and grow together.

1: Establish a cross-functional working group. One of the keys to success is working across the organization. When talking to our customers that are interested in creating OSPOs, one of the first questions they usually ask is where should that OSPO be? In legal? In engineering? The answer is that you’ll need to work with all of them. Microsoft has a cross-functional group with active participation from our legal department, marketing, the office of the Azure CTO, business units, engineering tools, and more. This cross-functional group helps guide policy and drive change throughout the organization. Every company has different structures and an OSPO often originates where someone sees a need. No matter where the OSPO “sits” in the organization, it’s important to bring in stakeholders from different business functions. After a year, reassess if OSPO is in the right place and if the right people are involved.

2: Document policy and find your champions. Microsoft’s open source software policy is documented in detail on our intranet for all our employees. We also have a group of experts from across the organization that are available to answer questions. To help others get started, we share a summary of our policy publicly. We periodically update our policy, vetting it with a cross-organizational group of Open Source Champions and then with our Open Source Executive Council — a group of executives from across Microsoft businesses that share their open source strategies and best practices with each other. In addition to input on policy, these champions help disseminate information back to their teams, help encourage open source usage, and can provide guidance to their peers when needed. For example, the Dapr team at Microsoft recently included community feedback in their decision making which led to them to prioritize work on a streamlined API to retrieve application secrets — this work was not in their current planned work cycle, but the community advocated this would help solve a lot of developer challenges so the team adapted and prioritized the API, which led to pick up from customers as well.

3: Give employees autonomy through policies and tools. The role of OSPO is to set clear policies, empower employees with knowledge and tools, and make it easy for people to do the right thing. The OSPO is there to provide training and to facilitate conversation between teams, and then allow each developer and business group to decide how to incorporate open source software into their business strategy. At Microsoft, all of our groups use open source software, but how they contribute and what they decide to open source might look different in the developer tools group than in Microsoft Office. Tools also provide autonomy and make it easier for employees to use open source effectively and in compliance. When a team at Microsoft creates a new repo, a wizard walks them through the process of creating it, setting a good Code of Conduct and support processes as well as kicking off any legal and business reviews needed internally. We’ve open sourced some of our tools and processes as projects such as ClearlyDefined or, in conjunction with the Linux Foundation, OpenChain. We list our open source tools and,  in addition, we use and collaborate on an open source software project called Tern as part of our internal tooling for identifying components in containers in order to make sure we correct for vulnerabilities quickly.

4: Learn from and collaborate with others. Get involved with groups and foundations to help on your journey. Open source is inherently community-driven and learning from others and sharing best practices will only strengthen your own open source program. We participate in various open source industry groups and foundations such as the Open Source Initiative, The Linux Foundation, The Eclipse Foundation, The Cloud Native Computing Foundation, and many others. We’re also active in the TODO Group, comprised of OSPO leads that meet biweekly to talk about OSPO best practices, where we’ve had recent conversations around securing the open source supply chain, and we share the practices we’ve each put in place and the tools that we can create together to solve common problems. Last year, Microsoft came together with GitHub, Google, IBM and others to create the Open Source Security Foundation (OpenSSF). The group is helping developers with resources to identify security threats to open source projects, providing education and learning resources, and finding ways to speed up vulnerability disclosures.

5: Provide rewards and motivation. Lasting culture change requires alignment with rewards and compensation. At every performance review, Microsoft employees are asked to describe how they are empowering and building on the work of others — this is very aligned with open source practices. Additionally, open source is an officially recognized core aspect of the developer skillset at Microsoft. In addition to recognizing individuals for their efforts, we’ve also brought together a group of “open source champs” from across the company that shares and learns open source best practices from each other and brings these learnings back to their groups. This gives them cross-organizational visibility while increasing their skillset and enabling them to use their knowledge to empower others.

Open source is core to nearly every company’s technology strategy and it’s important that all businesses think about how to empower their developers to use the software effectively and securely. We continue to learn and grow every day and we share our learnings in the hope that it helps others get started. You can visit our Open Source site which provides details on our open source activity and projects, as well as our policies, tools, and resources we use to guide our open source program internally.

A newsletter digest of the week’s most important stories & analyses.