Faster inference for PyTorch models with OpenVINO Integration with Torch-ORT
Many developers opt to use popular AI Frameworks like PyTorch, which simplifies…
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:
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.
There were five types of criteria we applied to data-driven nominations and qualitative alike:
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.
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.
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.
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.
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.