Published 2022-05-31 by Seth Michael Larson
Reading time: 6 minutes
Subscribe for more content like this through the mailing list or RSS.
For many open source consumers the "logical units" being depended on are libraries. However, the libraries themselves are only a product of what consumers are actually depending on: people.
You're likely to recognize the names of popular Python libraries like numpy, Requests, and Django. But could you name the maintainers of any of those libraries? How about the maintainers of transitive dependencies or who triaged your bug report last week?
This isn't a unique situation for the Python ecosystem, all open source ecosystems are structured similarly. Thousands of hours of labor are hidden behind every call to $ pip install
installing a package. The modern software supply chain is both miraculous and terrifying.
Production and consumption of open source software is maturing for the better and along the way we shouldn't forget that the leaves in our dependency trees are living and feeling people.
This article uses examples from the Python ecosystem but likely applies to many ecosystems and projects.
There are many projects and people that go uncounted due to their place in the dependency tree or circumstances of the ecosystem. Projects for tooling and infrastructure around packaging are severely undercounted in terms of "number of dependents".
These are tools like pip, twine, and virtualenv and infrastructure like PyPI. pip itself only has ~80,000 dependent repositories listed on GitHub because pip is not typically listed within a dependency list or lock file. It's obvious to anyone who knows the Python ecosystem that this isn't representative of pip's actual number of dependents which is roughly every person installing any package from PyPI.
The people behind projects are also severely undercounted. Counting "maintainers" is typically done using metadata from package repositories like PyPI because there are no other easy ways to programmatically gather this information. Using this method leaves out many maintainers that aren't listed in package metadata. Maintainers don't exclusively manage releases and write code, they also secure funding, mentor new contributors, triage issues, and review pull requests. None of these tasks are captured by only looking at package metadata and commit authors.
Dependency lists and metrics are becoming important to the companies waking up to the importance of supporting open source software. Organizations are suddenly needing to traverse their dependency tree to see who they've quietly been dependent on for years. When projects and maintainers aren't on the traversal path they're at risk of being left out of discovery for financial support, recognition, and hiring.
This is a disservice to everyone: maintainers lose out and organizations aren't supporting people they're depending on.
When doing dependency analysis don't forget to include tools and infrastructure in your search. Your team likely depends on these projects equally if not more than application dependencies.
The Spotify FOSS fund aims to support projects that aren't corporately backed, align with company values, and are actively maintained. The initial amount for the fund is €100,000 with the goal of supporting even more projects in the future. Projects were selected using dependency data across repositories in addition to nominations from developers.
Sentry published their FOSS Fund 155 which gave nearly $155,000 to open source maintainers. The amount donated was calculated using an article written by Gratipay founder Chad Whitacre which recommends a $2,000 donation per engineer per year. Sentry's donation included a range of donations to foundations like the PSF and projects like Psycopg and Vue.js. The projects receiving donations were determined using dependency analysis and asking for employee nominations and votes.
Indeed announced the FOSS Contributor Fund blueprint which aims to help interested organizations democratize financial contributions to open source by allowing employees who contribute to open source to vote on which projects receive funds every quarter. Nomination criteria for projects include being in use by the organization, using an OSI approved license and having an approved mechanism for receiving funds. Example funding mechanisms include Open Collective, Patreon, PayPal, and GitHub Sponsors.
Indeed also sponsors over 100 individuals on GitHub Sponsors. The focus on individual sponsorships in addition to projects and organization aligns with what we know about how open source works today: a small number of contributors make up a large amount of the total contributions per project and typically maintain multiple projects.