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
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
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
3: Give employees autonomy
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
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.