5 things we learned from sponsoring a sampling of our open source dependencies 

Microsoft supports and invests in the open source ecosystem in many ways. One such effort has been the Free and Open Source Software Fund Program (FOSS) Fund program, which has historically relied on employee nominations and voting to determine sponsorships of our dependencies.  This month, we were excited to experiment with advancements in this program and of our capabilities through a data-driven approach.  

This experiment focused on programmatically selecting a sampling of dependencies for bulk sponsorship through GitHub Sponsors.

Our experiment’s goal was to identify open source projects for sponsorship through deep analysis of our dependencies leveraging, metadata from Ecosyste.ms, an external supplier of open data about packages and source repositories, our inventory of our internal dependencies, as well as application of CHAOSS metrics for sustainability. We made room for nominations from employees as well. Ultimately, we sponsored 175 open source sponsorable entities (either maintainers or organizations that met criteria detailed below) representing 266 open source repositories and 396 unique packages with grants that ranged from USD1,000 to USD12,500—here are five things we learned, and are quite honestly still figuring out: 

#1 Inventory and metadata of dependencies is critical to isolating projects for sponsorship with a lens for sustainability

Free and Open Source Software Fund Program (FOSS) Fund program, which has historically relied on employee nominations and voting to determine sponsorships of our dependencies.  This month, we were excited to experiment with advancements in this program and of our capabilities through a data-driven approach.  

Candidates for sponsorship were derived from metadata analysis of tens of thousands of dependencies. The analysis combined our internal inventory of Microsoft dependencies with package and source repository metadata, largely from Ecosyste.ms (whose main developer, @andrew was sponsored this round). If you don’t already have an inventory of your dependencies but use GitHub, we recommend using the GitHub dependency graph to find all the dependencies used across an entire GitHub Organization. 

By placing all the related metadata fields into tables in Microsoft Azure Data Explorer, we were able to use the Kusto Query Language (KQL) to analyze tens of thousands of dependencies and repositories. This approach allowed us to drill down to the individual packages meeting our criteria (described further in this post), and to map those packages to source repositories where a second set of criteria could be applied. 

#2 Setting quantitative criteria for sponsorship beyond number of use and popularity was massively helpful in zooming in on problems we want to help solve 

There were five types of criteria we applied to data-driven nominations and qualitative alike: 

• The repository and sponsored entity need to not be a Microsoft project or a Microsoft employee: we leveraged the source repository’s organization name and an internal (and opt-in) mapping of GitHub usernames to Microsoft employees to filter these out. 
• Projects must have Open Source Initiative (OSI) approved license. Data for this came from Ecosyste.ms. Any license not in this list, received a manual review. 
• We needed projects to have GitHub Sponsors enabled in the source repository and transparency of where funds will go to ensure alignment with governance. A FUNDING.YML is a great way to make project funding transparent as it can direct multiple funding methods and sponsorable entities. In absence of this file, we also accepted the GitHub Sponsors sidebar list of sponsorable entities. We saw many FUNDING.YML with invalid formatting, so please review the GitHub guidance to ensure your project’s funding can be detected programmatically! 
• All projects needed to be active in the past year based on commits to the source repository or a published package update. 
• Lastly, for a portion of the sponsors we tried to target open source dependencies that were (perhaps) less top-of-mind for developers and therefore not-typically what we see nominated for FOSS Fund. For example, projects that are dependencies of top-level packages and maintained by very few people instead of a big organization with a well-known brand.

We also conducted qualitative analysis of every single sponsorship. While we did this with the purpose of catching concerns missed by data analysis, what we found was a simply impressive network of professional and dedicated maintainers. 

#3 We need more projects to accept GitHub Sponsors 

GitHub Sponsors is fast and easy for corporations like Microsoft due to all payments going out as a single invoice. We acknowledge this isn’t perfect as many of the components identified in our initial filtering set did not have GitHub sponsors enabled. Lack of GitHub Sponsors filtered out many more projects than license issues, ownership conflicts, or lack of activity. It’s easy to setup GitHub Sponsors. 

#4 We need more metadata for strategic decision-making 

We noted geography and saw an organic diversity of region including Canada, United States, Portugal, Turkey, Germany, United Kingdom, Switzerland, France, Bosnia and Herzegovina, India, Indonesia, Ireland, and Czech Republic among others. 

We were also pleased to see projects across Rust, Python, .NET, JavaScript/TypeScript, Go, Java, C++, and other languages. 

Future funding campaigns might focus on a region, language or technology where we want to support more open source innovation, and this experiment helped us understand how we might do that. 

#5 Fine tuning funding amounts 

We took an approach to start with a USD500 baseline and then incrementing based on number and scale of projects, individual or organization entity, specific “requests for support” in the sponsors’ profile, and employee advocacy. The final grants ranged from USD1000 to USD12,500. We’re definitely learning here. 

Trying to determine the amount raised more questions about other ways we could be supporting this sampling of maintainers. For example, it would have been wonderful to see financial goals of maintainers on their sponsors pages, as well as other types of sustainability “asks”—those might be things like security mentorship, new maintainer onboarding, contribution gaps, governance development and really anything that comes to mind as helping a project sustainability. We’re listening! 

We are also interested in thoughts about how we can unify around such a standard for presenting and fulfilling sustainability requests. 

We want to collaborate

Thanks for reading! 

We’ve seen a lot of excitement around this wave of sponsorships, and we know there will be criticism too. That’s Okay. We’re trying things and will continue to share and iterate on this work with CHAOSS, FOSS Funders, and anyone else who wants to collaborate. 

This is just only one small way Microsoft is experimenting with and investing in sustainability of the open source ecosystem. For more on our efforts, which include upstream contributions, Azure Credits, and Foundation sponsorships, including the Open Source Security Foundation (OpenSSF) you can check out the Microsoft Open Source Ecosystem page. 

If you would like to understand the security posture of your own repository that builds a package, we recommend checking out OpenSSF’s Scorecard GitHub Action. 

To find a full list of maintainers and associated projects, check out the FOSS Fund README, or check out our “how to” pseudo code description of the data analysis process in our OSPO public GitHub repository. Please reach out to opensource@microsoft.com with any questions. You can also often find us in the CHAOSS OSPO and FOSS Funder’s working groups.

Emma Irwin

Principal TPM, Microsoft Open Source Programs Office (OSPO)

Emma Irwin is a Principal TPM with Microsoft's Open Source Program's Office. She has over 20 years' experience building with and for open source projects and their communities. Her experience spans multiple ‘open’ ecosystems including open data, education, science, access and innovation with recognized expertise in open source engineering, sustainability, security, metrics, D&I and community building.

See more articles from this author

Justin Gosses

Senior Technical Program Manager

Justin’s work in Microsoft’s Open Source Program Management Office has improved safety, efficiency, and effectiveness for Microsoft’s thousands of developers who work on Open Source. He has built data driven experiences that assist developers evaluating open source packages, measure business impact of open source, and track upstream contributions to the open source projects.

See more articles from this author