Microsoft Open Source Programs Office—Tuning the answers to Open Source questions

Microsoft Open Source Programs Office (OSPO) operates with a small technical program management team. Instead of trying to cover every aspect of open source, our focus is on achieving specific impact needed to scale and sustain excellence in Open Source (OSS)—in partnership with businesses across the company. We see the OSPO as a crucial instrument within a larger company symphony.

With collaboration and partnership in mind, we also think of our OSPO as part of an even bigger ensemble of companies, academic institutions, non-profits, communities, and individuals working to get better at Open Source—we are super excited to be attending the Open Source Summit in Seattle on April 16, 2024, and to kick off some sharing and collaborating in this blog post.

Our focus this past year has been on security, business excellence in OSS, safety, and supporting our upstream—a focus derived from questions and problem statements coming in from every corner of the company, and broader ecosystem. Primarily, answers to these questions involve great data science, solid standards development, and efforts to empower, inspire, and motivate humans at the center of it all.

Below you’ll find some of the questions we’ve been asking, and ways we’re experimenting with answers:

Data and GitHub repositories 

Data is at the center of all we do. Of course, data alone is not a magic thing—it takes time to understand what questions are most important to ask and where that data can be found, accessed, and presented in a way that results in impact.

Data is at the center of all we do. Of course, data alone is not a magic thing—it takes time to understand what questions are most important to ask and where that data can be found, accessed, and presented in a way that results in impact.

• Question: What might be the primary characteristics for grouping repositories? How can we provide different compliance experiences based on those characteristics?
  • Repository cohorts: creating standardized types of repositories via metadata helps us be more strategic in our many efforts to raise the bar for compliance and more. Check out this demo or code in the OSPO GitHub repository. Also check out Justin’s talk on this topic!

• Question: How do we help developers make good choices about the components they are choosing beyond a minimum bar of compliance? How can that tool help us understand sustainability risks and contribution needs once we take on that dependency? 
  • Component Information Dashboard: Using community health insights from Community Health Analytics in Open Source Software (CHAOSS), public information on packages from ClearlyDefined.io, OSSF, and Ecosyste.ms, we’ve built (and continue to improve) a prototype experience that surfaces attributes of heightened risk for sustainability. Come to our panel discussion on the topic: OSS Viability and Project Selection.

• Question: With the xz backdoor human exploit a primary topic at the Open Source Summit, what metrics can we share and collaborate on with others? 
  • One thing might be, some experimentation we’re doing with CHAOSS metrics called the ‘Nebraska Factor’ metric (after the well-known XKCD cartoon); and discussing where human observations fit. Find us at the summit or CHAOSS OSPO working group to chat more on this topic. 

• Question: How can we help Microsoft developers describe the impact of their upstream open source contributions beyond their own needs/impact?
  • Rewards season personalized maintainer emails: Often, an upstream contribution helps other teams at Microsoft. We’ve created personalized ‘maintainer emails’ to show exactly how many other projects benefited from a contribution. Sometimes it’s in the hundreds! This directly demonstrates ‘contributions to the success of others’, which is an aspirational area of impact for all Microsoft employees.

• Question: How can we help Microsoft developers/teams of open source packages learn more about their internal impact?
  • Component Intelligence: A suite of pre-built Kusto queries and dashboards that Microsoft developers can request access to that maps out internal usage of packages by repository, service, organization, etc. This helps them see real examples of their code being used, tell stories about usage in key products, locate potential candidates for user interviews, and track changes in usage rates by version and package over time.

• Question: How do we avoid the pitfalls that come with persistent admin access, but still permit elevated actions by repository owners? 
  • Mandatory JIT (“Just in Time”) for all GitHub repositories tied to Microsoft’s internal engineering system assets and inventory systems.

• Question: How do we ensure that our GitHub repositories contain required files, but that they are the most up to date version? 
  • GitHub repository linter and policy service to submit PRs to repos missing files, or where content might be out of date.

• Question: How do we help maintainers keep their repositories secure? 
  • Among (many) other efforts, we provide an up-to-date OpenSSF Scorecard value for each repository available, with recommendations for action

When it comes to data, the challenges we encountered have been around access to data (mostly that people must make multiple data access requests and then wait) and making insights not just visible but also actionable. That gets to the human side of things.

Humans in focus 

Life is busy, days are busy and there’s a lot of noise! Here are some problems we’ve looked to solve in motivating, inspiring and creating actions with the fabulous humans of open source (internal and external).

• Question: How do we teach people new to open source to think and plan strategically, realistically, and within their ability to resource?
  • After talking with a lot of successful teams, we built an ‘Open collaboration as a strategy’ resource with a central image of OSS being a cycle and not any one destination. We published a version of that in our OSPO repository.

• Question: Who is our key audience for standards and other OSS efforts and what’s the best way to communicate with them? 
  • Our communication strategy built three new capabilities this year, for our identified key audiences. The first was ‘campaigns’ as companion to outreach, the second ‘Frustration funnel’—our name (that stuck) for encouraging people to share ideas, frustrations, and problems in one place for visibility and validation—potentially for action. “New” means we’re still learning, of course!

• Question: How do we ensure open source developers and their teams feel supported, safe, and can access timely incident responses while working in the open? 
  • Based on a successful effort in the .NET project, a new replicable model for escalation across multiple organizations, an ‘OSS Reporting Program’, triages escalations or requests for mentorship support for numerous reasons: code of conduct, PR concerns, tooling request (like GitHub bans), and observations of sustainability risk.

• Question: How do we help maintainers set boundaries, effectively moderate discussion channels, and turn up as their best selves in the open? 
  • Thinking of enforcement as a ‘stack’ where the Code of Conduct is a global variable, we’ve created a ‘Pocket Guide’ for enforcement to help teams set moderation goals (participation guidelines) for their project and community. Find a version of this in our OSPO repository.

• Question: How do we keep our business reviewer process healthy, with Open Source reviewers often changing roles, or as new organizations spring up? 
  • Community management: While the process for reviews is triggered and moved by systems, the success of the people in the process is forefront in our business review process. Tracking and empowering business reviewers across Microsoft requires a community management approach of onboarding, empowering, and connecting. It’s daily work.

• Question: How do we help employees and teams understand and advocate for investment in upstream? How do we communicate our overall investment internally/externally?
  • Among many efforts, we’re experimenting with the standardization of a framework to help employees surface opportunities for investment that might not otherwise be visible. We’ve shared the first draft of this ‘OSS investment framework’ with the FOSS Funders group and have initially piloted as part of the most recent fund. 

If you have any questions, please reach out—if you are in Seattle for the summit, please visit the Microsoft booth to say hello, or attend one of our talks/panels:

• Panel: OSS Viability and Project Selection
• Repository Cohorts: How OSPOs can programmatically categorize all of their repositories