2020 fundamentally changed how many companies and teams work—seemingly overnight, remote-first cultures became the new norm and people had to change how they communicate and collaborate. However, for those of us who have been deeply engaged in open source, remote work has been our norm for many years because open source communities are large, globally distributed, and require effective collaboration from developers around the world. We’ve had ample time to create and refine many digital-first practices.

It’s no surprise that open source adoption and usage grew significantly this year. New data from GitHub’s 2020 Octoverse report shows there were over 60 million new repositories created this past year, and more than 56 million developers on GitHub. When people had to stay home, developers came together to find community and connections through open source. And though open source developers had a lot of established remote practices, this year challenged companies of all sizes to integrate their open source software experiences and development models in new ways, bringing new learnings as a result.

We wanted to share four places where Microsoft is learning from and growing our engagement in open source over the last year that we hope can be useful for any developer or team looking to build and collaborate in 2021.

1. Seeking different perspectives makes better software

Success in open source is just as much about your own contributions to the community as it is about what you learn from the community. Behind every pull request, issue, and code snippet, is a person. It’s important to connect with them—to listen, learn, and empathize with them. They offer a different perspective and feedback that your team may not be thinking of.

I hear conversations in meetings (one of the new virtual hallways) about making sure we get feedback from industry users who are well outside the Microsoft faithful. With this new feedback, I hear a collective sound of Microsoft’s perspective expanding and our gratitude for the new and different views we are receiving.

One example of community feedback changing our perspective was when the Dapr project received a lot of user feedback requesting a streamlined API to retrieve application secrets. The Microsoft team working on Dapr had not planned that work in the current cycle, but the community made it very clear that this new API would solve a lot of problems that developers were facing.

The Dapr maintainers worked closely with community members who submitted multiple PRs to add this functionality, covering everything from code to documentation to samples. After this was added, we found that customers also picked up this functionality and used it in their Dapr implementation.

This reminded us that listening to community feedback is extremely valuable, and that given opportunity, encouragement and support, community members will contribute effort to make requirements a reality.

2. Finding the balance between policy and autonomy

To help drive Microsoft’s open source efforts, we have an Open Source Programs Office (OSPO), whose goal is to help our employees consume and participate in open source safely, effectively, and easily.

Over the last year, we have heard from more and more enterprise customers—from retailers to banks to auto makers—who are looking to establish similar offices and practices internally. We share and discuss best practices on how to find the balance between setting policy while also empowering employees to do the right thing. While OSPOs will look different depending on your company’s needs, a few common practices we often discuss include creating a cross-functional group, setting clear policies (and making them easy to find and understand!), investing in tooling, and providing rewards and motivation. We’ve shared our guidance and policies and we look forward to continuing to build out our own internal practices, and to share our learnings along the way to help others do the same.

3. Securing every link in your supply chain is critical

Using open source in your development process has many advantages, including increased time to market, reduced cost of ownership, and improved software quality. However, open source, like any software, has its risks—open source can contain security defects that lead to vulnerabilities—and new research shows security vulnerabilities often go undetected for more than four years before being disclosed. Because open source software is inherently community-driven, there is no central or single authority responsible for quality and maintenance. Source code can be copied and cloned, leading to outsized complexity with versioning and dependencies. Worse yet, attackers can become maintainers and introduce malware.

As more systems and critical infrastructure increasingly rely on open source software, it’s more important than ever that we build better security through a community-driven process. Securing open source is an essential part of securing the supply chain for every company. In 2020, we came together alongside 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. In the coming year, the OpenSSF looks to provide hands-on help to improve the security of the world’s most critical open source projects.

4. Over communicate

Big companies and big open source projects know that important information has to be communicated broadly and frequently across different channels. Even with this knowledge, Microsoft had to change rapidly this year just as so many other companies did. We no longer had moments of serendipitous interaction where you learn something helpful from bumping into someone in the coffee line, walking with a colleague to a meeting, or waiting with someone for the elevator.