8,874 packages 255,206 versions
Helm charts have their own dependency trees, versioning schemes, and security considerations, but until recently they’ve been largely invisible in supply chain analysis tooling. Having them indexed means users can trace dependencies from application code down to the infrastructure it runs on.
21,451 packages 185,351 versions
Same story as Helm but for infrastructure provisioning. Terraform modules are deeply nested and widely depended upon, and now they’re queryable through the same API as every other ecosystem we track.
11,293 packages 107,938 versions
The open alternative to the Visual Studio Code Marketplace, used by Eclipse Theia, VSCodium, Gitpod, and other open source editor distributions. Extensions are a growing attack surface and tracking them alongside traditional package ecosystems gives a more complete picture of developer toolchains.
1,019 packages 7,002 versions
The Bazel Central Registry tracks modules for Google’s build system, widely used in large monorepos at Google, Uber, Stripe, and elsewhere.
1,905 packages 5,646 versions
The leading package manager for C and C++ libraries. C/C++ has historically been underrepresented in supply chain datasets despite being the foundation of most operating systems and language runtimes.
143,132 packages 154,704 versions
The package collection behind the Nix package manager and NixOS, with reproducible builds as a core principle. One of the largest single-registry ecosystems we track.
34,734 packages
Debian is one of the oldest and most widely used Linux distributions. System-level packages are the base layer that everything else sits on, and tracking them alongside language-level registries closes a significant gap in dependency analysis.
37,306 packages
Built on top of Debian, Ubuntu’s repositories include both inherited Debian packages and Ubuntu-specific additions. Tracking both gives a complete view of the two most popular Linux packaging ecosystems.
30,573 packages 31,409 versions
A functional package manager similar in philosophy to Nix but built on GNU Guile Scheme, used both as a standalone package manager and as the basis for the Guix System distribution.
6,886 packages
The Comprehensive TeX Archive Network has been home to LaTeX packages since 1992, serving a huge academic and publishing community that rarely shows up in software supply chain conversations.
10,548 packages 12,470 versions
The Image Packaging System for illumos-based distributions, indexed via the OpenIndiana Hipster repository.
All eleven are available through the packages API and open data releases. If there’s a package registry you’d like to see indexed, open an issue on the packages repo or get in touch at hello@ecosyste.ms.
]]>Saturday, 31 January 2026
Room K.3.201 (capacity 80) / 10:30-14:25
Adam Harvey / 10:30-10:55
Adam walks through a phishing attack that targeted owners of popular Rust crates in September 2024. The talk covers how the attack unfolded and how collaboration between the Rust Project, Rust Foundation, and Alpha-Omega helped shut it down quickly.
Zach Steindler / 11:00-11:25
Zach surveys how npm, PyPI, RubyGems, and Maven Central have adopted attestations to link packages to their source code and build instructions. He’ll explain Sigstore bundle verification, compare implementation approaches across registries, and discuss what this means for ecosystems that haven’t adopted attestations yet.
Gábor Boskovits / 11:30-11:55
Gábor examines how different package managers handle dependency resolution through the lens of reproducible builds. The talk compares language-specific lock files (Cargo), traditional distribution packaging (Debian), and declarative approaches (Nix, Guix).
Ryan Gibb / 12:00-12:25
Ryan introduces the Package Calculus, a formal framework for unifying how different package managers resolve dependencies. The talk addresses three problems: multi-language projects can’t express cross-language dependencies precisely, system and hardware dependencies remain implicit, and security vulnerabilities in full dependency graphs are hard to track.
Matthew Suozzo / 12:30-12:55
Matthew argues that reproducible builds aren’t enough if you don’t understand what happens during the build itself. He presents OSS Rebuild’s open-source observability toolkit, including a transparent network proxy and an eBPF-based system analyzer for detecting suspicious build behavior. The talk responds to supply chain attacks like the XZ backdoor.
Philippe Ombredanne / 13:00-13:10
Philippe traces Package-URL’s journey from its FOSDEM 2018 debut to becoming an international standard for referencing packages across ecosystems. PURL now appears in CVE formats for vulnerability tracking and is used by security tools, SCA platforms, and package registries for SBOM and VEX generation.
Vlad-Stefan Harbuz / 13:15-13:25
Vlad tackles a gap in package management: while source dependencies are well documented, binary dependencies like numpy’s reliance on OpenBLAS binaries remain invisible. He proposes a global index of binary dependencies using a linker that tracks symbols across the open source ecosystem.
Michael Winser / 13:30-13:55
Michael examines why package registries struggle financially despite being used by almost all software. Most rely on grants, donations, and in-kind resources while facing increased costs and security expectations. He discusses how the Alpha-Omega project has funded security improvements and piloted sustainable revenue models with major registries.
Mike McQuaid / 14:00-14:25
Mike discusses Homebrew’s v5.0.0 release from November 2025, covering what other package managers could learn from Homebrew’s approach and what Homebrew has adopted from elsewhere.
See you in Brussels on January 31st.
]]>ecosyste.ms is in something of a unique position: having aggregated and normalized package data from over 70 sources we know something about how package managers work, and how they differ from one another.
Working alongside the CHAOSS Package Metadata Working Group and Alpha-Omega we’ve documented the similarities and differences across package registries and clients, publishing eight repositories of information about how package managers work today. In doing so we hope to identify common problems and work toward better practices:
A cross-reference table of commands across 48 package managers. When you switch from npm to cargo, or pip to poetry, this maps the equivalent commands between ecosystems.
The data is extracted from manpages and --help outputs and stored as JSON files in data/managers/ with generated markdown tables and CSV exports.
Check out the whole csv file rendered as a huge table here: github.com/ecosyste-ms/package-manager-commands/blob/main/commands.csv
Over 145 manifest and lockfile examples from 34 package ecosystems, organized by PURL type.
Manifests include package.json, requirements.txt, pyproject.toml, Cargo.toml, Gemfile, composer.json, go.mod, pom.xml, and more. Lockfiles include package-lock.json, yarn.lock, poetry.lock, Cargo.lock, Gemfile.lock, composer.lock, go.sum, and others.
Initially extracted from Bibliothecary, with additional examples from tools like Trivy, Syft, OSV-Scanner, and Grype. Each example documents its filename, type (manifest/lockfile), source project, and what features it demonstrates.
OpenAPI 3.0 specifications for 25+ package registry APIs including npm, PyPI, Maven, RubyGems, Cargo, Docker, and Terraform.
Most schemas are generated using the packages.ecosyste.ms mapping code. Two registries, crates.io and open-vsx.org, have official OpenAPI specs. Hopefully more registries will publish official specs in the future.
You can use these specs to generate API clients, create documentation with Swagger UI, or build mock servers for testing.
RSS and Atom feeds for tracking releases from package managers, registries, and related infrastructure projects. Import the OPML file into any feed reader to follow updates from npm, pip, cargo, Homebrew, Docker, Renovate, Dependabot, and others.
Feeds are organized by language and ecosystem.
A reference documenting lifecycle hooks across package manager ecosystems, categorizing them into two types: package-defined hooks (scripts embedded by package authors that execute during installation, building, or publishing) and system/plugin hooks (extension points for users and tools to modify package manager behavior globally).
Covers hooks across npm, Yarn, pnpm, Cargo, pip, Composer, RubyGems, Maven, Gradle, and many others. For each ecosystem, it documents when hooks execute, their implementation mechanisms, and security implications.
Documentation of archive formats used by package managers, covering both language-specific ecosystems (gems, wheels, npm tarballs, crates) and system-level formats (deb, rpm, apk).
Each entry documents internal archive structure, compression methods, metadata file locations, implementation quirks, and edge cases that commonly cause problems. Ruby gems use nested gzip compression within tar archives; Python wheels are actually ZIP files with specific metadata requirements; npm packages employ pax extended headers for long filenames.
A reference documenting dependency resolution algorithms across package managers. Covers nine algorithm families: SAT solving (Composer, DNF, Conda), PubGrub (Dart pub, Poetry, uv), backtracking (pip, Cargo), minimal version selection (Go modules), deduplication with nesting (npm, Yarn, pnpm), version mediation (Maven, Gradle, NuGet), Molinillo (Bundler, RubyGems), and others.
Each section explains how the algorithm works, its trade-offs, and why certain package managers chose their approach to solving dependency hell.
These repositories collect what we’ve learned while researching the space. If you’re building parsers, SBOM generators, or tools that work across package ecosystems, these might be useful references.
All eight repositories are released under CC0 1.0 Universal and accept contributions if you have corrections or additions.
]]>Submission deadline: 1st December 2025
Package managers are critical infrastructure for developers and end users alike, handling dependency resolution, licensing, reproducibility, provenance, software supply chain security, and long-term maintainability. As ecosystems proliferate, package managers face recurring challenges: dependency solving, namespace collisions, reproducibility, metadata standards, binary vs. source builds, supply chain security, and cryptographic signing of artifacts.
The Free and Open Source community has built dozens of package managers across operating systems (Debian’s APT, Fedora’s DNF, Arch’s pacman, Nix, Guix), programming language ecosystems (PyPI/pip/uv, npm, Cargo, RubyGems, Conda, Pixi), domain-specific tools (Spack, EasyBuild for HPC), and universal formats (Flatpak, Snap, AppImage). Each has made unique trade-offs and innovations.
This devroom provides a gathering place for maintainers, researchers, and users of package managers to discuss lessons learned, new developments, and common infrastructure challenges. It’s a neutral forum where different communities can meet, exchange ideas, and foster collaboration on universal issues.
Submit your proposal through the FOSDEM pretalx system: https://pretalx.fosdem.org/fosdem-2026/cfp
Important: Select “Package Managers devroom” as the track in the dropdown menu.
Please include:
All speakers and attendees are expected to follow the FOSDEM Code of Conduct. By submitting a proposal, you agree to abide by these guidelines.
If you have any questions about the devroom or your submission, please reach out to w.vollprecht@gmail.com.
We especially encourage submissions from individuals and communities underrepresented in free and open-source software.
Looking forward to your proposals!
Devroom Organizers: Wolf Vollprecht, Andrew Nesbitt
]]>Earlier this year we launched Ecosystem Funds, a way to support all your critical software dependencies. We packaged millions of the most critical open source components into a few hundred Funds, each centred on a language, framework, or package, turning a process that can take months into a five minute conversation with your CTO.
But what happens a year later, when you need to justify that investment?
We know that many of the organisations supporting open source today do so because of a few dedicated people, deep within the belly of their corporate structure, doing the good work of convincing leadership that it’s a good idea. These unsung heroes do what they can to justify their proposed investments across multiple departments and budgets. They point out to marketing that the sponsorship of a popular package will expose their brand to developers eyeballs, and they tell HR that hiring and retaining developers is easier when they know their organisation is giving back. But they rarely talk to engineering about the direct benefits of supporting open source projects.
Why?
Because it’s hard. Because the tools to do so today require you to understand both how and what to measure before weaving that into a story that matters to you. You need to understand how the craft of software development shows up, and how open source communities work together, to understand whether that community is sustainable, and what sustainable even means.
We want to change that.
Ecosystem Dashboards are designed to shift the conversation toward the benefits (and thus the budgets) directly associated with creating vibrant, productive and sustainable open source communities on which we can all depend.
Ecosystem Dashboards are designed to get you started quickly, to give you an accurate picture of where projects are today, and where they’ve been in the past, so you can justify the return on the investments you have made over the previous month, quarter, or year.
Ecosystem Dashboards is built on ecosyste.ms, the world’s most comprehensive database about open source production and use, but we’re not here to overwhelm you. Instead we’ve packaged each dashboard, containing a single project or a ‘collection’ into eight facets:
Productivity: How well is this community working together?
Responsiveness: How well is this community able to deal with the pressures placed upon it by users?
Finance: What resources does this community have at their disposal, and how are they using them?
Engagement: How well is the community distributing its workload, and is the community growing?
Adoption: How critical is this community to the ecosystem(s) they’re a part of, and how popular are they?
Dependencies: What software does this community depend upon, and how are those communities doing?
Packages: What software does this community publish, and how popular are those artifacts?
Security: How well is this community handling security threats, and what tools do they use to do so?
Ecosystem Dashboards are a free resource for maintainers, program managers, researchers and policymakers, supported financially by a small group of sponsor organisations like Open Source Collective.
]]>As we mentioned last week: ecosyste.ms is at capacity. Revenues and donations to our non-profit are no longer covering the cost of serving 500GB of data and 40m requests daily.
A few weeks ago we introduced user agent tracking in order to get a better picture of our user’s behaviour. Our findings were…. interesting. Our biggest users make nearly 3m requests to our packages service over a three day window. To put that into context: every day around 30,000 new versions of packages tracked by ecosyste.ms are published. So, to encourage more efficient and responsible use of our services, and to enable us to support that service now and into the future, we will be introducing rate limits, the right way:
Inspired by OpenAlex, who themselves were inspired by Crossref, we’re going to split API users into two pools: the polite pool, and the common pool.
The polite pool will have more consistent response times, ‘it’s where you want to be’ as OpenAlex say. In order to get into the polite pool you will need to provide a contact email address, so that we can contact you should we need to rate limit or block your access. You can do this by:
mailto=you@example.com as a parameter to your API request, like this:mailto:you@exmaple.com somewhere in your user-agent request headerThe common pool is for everyone else. It will have less consistent response times, especially during peak periods as we serve polite requests more frequently.
For the next couple of months we will continue to run the service without strict rate limits. Meanwhile we will work with our users to establish a policy that treads the line between supporting non-commercial applications, research, and policy development, while providing additional revenue to cover the cost of hosting and maintaining ecosyste.ms’ services.
In the meantime you can support the project by:
👩💻 Contributing to ecosyste.ms on GitHub
🤝 Purchasing a data licence
🙏 Donating on Open Collective
Three years later and ecosyste.ms has been used to launch a new kind of open source security company, expanded support for an established security product, and changed Microsoft’s approach to funding open source. We’ve helped countless others publish research on and/or fund open source software including The République Française, The Linux Foundation, The Chan Zuckerberg Initiative, The Sovereign Tech Agency, and The Digital Infrastructure Insights Fund.
Today ecosyste.ms serves 40m requests, comprising 300GB of data and 15m worker requests. Every. Single. Day.
But all is not well.
ecosyste.ms was developed with a simple goal: to build shared infrastructure for those seeking to create a sustainable and secure foundation of open source software. Infrastructure for infrastructure, if you will. This ethos extends to ecosyste.ms itself: our code and data are licensed (AGPL and CC-BY-SA respectively) to ensure that the community can use the services we provide, free of charge, if they contribute their work back to that same community.
That said, we know that commercial organisations have an important role to play in achieving our goal. So, for those that wish to operate an instance of ecosyste.ms or utilise ecosyste.ms’ data for their own use, we offer less restrictive licences, available to purchase through our non-profit host Open Source Collective (OSC). OSC are registered vendors to most large open-source supporting organisations - just email us to discuss terms.
And that’s just the beginning
ecosyste.ms is at capacity, both in terms of our ability to serve traffic, and to build the services we believe our users need. Revenues from licence sales are no longer covering the costs of hosting a service storing terabytes of data and serving 12m unique users every month. On top of this our users are asking for higher rate limits, priority traffic, and more data.
Happily we are working with a non-profit organisation to fund the next phase of ecosyste.ms’ development, which we hope to announce soon. Development will focus on traffic management, documentation, developer experience, a new plugin architecture, and a pubsub pipeline that allows users to process data for their own use, or contribute analysis back to the commons.
If that is of interest to you or your organisation contact us and we’ll include you in the development process. In the meantime you can support the project by:
👩💻 Contributing to ecosyste.ms on GitHub
🤝 Purchasing a data licence
🙏 Donating on Open Collective
At FOSDEM this year Ben (Open Source Collective) and Andrew (ecosyste.ms) spoke about a decade of working together in open source sustainability and ‘digital infrastructure’.
In that time they’ve built tools (libraries.io, octobox.io, 24pullrequests.com/) to help Open Source developers directly and, most recently, a set of digital services and data sets to aid and accelerate the work of policymakers, researchers and developers building toward a secure and sustainable future for open source, called ecosyste.ms.
Their most recent release, Ecosystem Funds, was built atop these services, in a matter of weeks, as a direct response to the Open Source Pledge. So we thought we’d invite them to tell us what it is, and why they’ve spent the past six months perfecting their process — including the distribution of $75k of funding from Sentry.
— Chad
With the lede thoroughly buried (thanks Chad!): yes, we’re here to talk about Ecosystem Funds, our take on the ‘fund the entire ecosystem’ playbook that others (StackAid, thanks.dev, FLOSSBank, BackYourStack and many more) have released over the past decade. While we support all of those platforms through the tools and services available at ecosyste.ms we wanted to offer a one-stop-shop for funders struggling to understand their core open source dependencies, and to develop and support the entire ecosystem of funding solutions while we do it.
Essentially Ecosystem Funds are curated sets of open source components that are the most critical (that is, most used) in their respective domains. We built funds at various levels of depth — there’s a Fund for Django, and one for the entire Python ecosystem — so that open source funders can make an informed decision about which projects to support, without having to do months of work to understand their software estate, and the mass of open source that’s critical to their work.
The slogan version of that is: We turn a three month audit into a five minute conversation with your CTO or VP Engineering.
From there we run the entire process for funders. No, really, we do.
We accept donations, allocate 100% of the funds to projects on a monthly basis, and manage the process of getting those funds to the maintainers using the platforms they choose to accept funds.
We support all funding platforms. Whether a maintainer uses GitHub Sponsors, thanks.dev, Patreon, Kofi, or any other platform, we direct donations where projects want to receive them. If a project has not indicated a platform in their funding.yaml we encourage them to look at the options available to them. Once they have chosen one, we direct donations there at the end of the month. For projects that do not choose a platform, we distribute funds directly to maintainers using Open Collective.
That might sound like a lot, but our partnership with Open Source Collective is the key: Ecosystem Funds is driven by the data-led approach of ecosyste.ms, which tracks 230m repos and billions of individual events, and Open Source Collective, who move ~$25m annually on behalf of their 2,500 member open source projects. Ecosystem Funds effectively drives Open Source Collective programmatically, instructing the team to make payments, all with double transparency both on each Ecosystem Funds page, and on the Open Collective platform.
At the launch of the Open Source Pledge we saw a huge challenge for organisations wishing to join: that they would have to decide how to distribute funds, and create a process to do so.
We take all that pain away, while developing and supporting the ecosystem of other funding solutions while addressing the HUGE gap that we have seen in open source funding solutions over the past decade: We’re only funding the software we see, not the software we actually use.
Our view is that, regardless of how you choose to judge an open source project, the projects that are the most used are the most critical. That’s it, end of argument.
But if you need a defence of that position: if your goal is to reduce your risk, or otherwise improve the ‘health’ (I know that’s a polarising term, but let’s go with it for the moment) of your open source dependencies then you have to support the whole ecosystem, not just the projects that appear in a cherry-picked group of SBOMs. If one of the unseen dependencies in your stack fails, your stack fails. And the likelihood that these dependencies, which are typically the most used in a given ecosystem, are your dependencies is extremely high.
In our talk at FOSDEM we demonstrated that there is a huge disparity between funding in open source that we can see, and the actual use (again, ecosyste.ms monitors over 230m repositories and nearly 11m packages) of those packages. We also showed that the usage we see within open source correlates well enough with downloads to say usage within publicly available software is representative of all use. This is key for Ecosystem Funds as we are asking companies to trust that our method for allocating funding will protect them individually.
But we have a problem:
ecosyste.ms (and by extension Ecosystem Funds) tracks around $52m of total funding for open source projects on Open Collective. It also tracks the funding status (but importantly not amounts) of sponsors on GitHub Sponsors. That is a speck in the ocean of the existing support dedicated to open source today.
The recently embattled NSF’s POSE program alone has distributed hundreds of millions of funding to open source communities, and the projects that they support. But it’s impossible to track the vast majority of resources that are dedicated to open source today, both directly in cash and indirectly through human labour. Without that we cannot make collectively informed decisions about where best to invest our efforts, and our donations.
Without more open data about the support for open source we can never say we are sustaining our collective, critical, digital infrastructure.
So we call on open source funders, other funding platforms, and open source projects themselves to share data, in a programmatically readable manner, about the resources they have today, and the resources they are currently in need of. We pointed to the 360Giving Data Standard, and the Open Contracting Data Standard as two examples of how we could do this today but we are more than happy to lead an effort to standardise this data over the coming months — contact hello@ecosyste.ms to join the conversation.
Finally we would also like to call out the work of organisations like Invest in Open Infrastructure, whose State of Open Infrastructure Report is doing some of the heavy lifting that we need to build a more representative picture of open source support today. We’d love to see more work like this by and/or funded by open source sponsors in the near future.
]]>A few, short weeks before the holidays we announced Ecosystem Funds; a collaboration between Open Source Collective and ecosyste.ms that makes it easier to support your critical software dependencies.
Using billions of data points from ecosyste.ms we’ve packaged millions of the most critical open source components into a few hundred Funds, each centred on a language, framework, or package, turning a process that can take months into a five minute conversation with your CTO.
We launched with a $67,500 commitment from Sentry to the Rust, Python, Django and Javascript Ecosystems.
We’ve since distributed over 80% of the funds in 375 individual payments to 136 projects. We’ve sent money to projects on GitHub Sponsors, Patreon, BuyMeACoffee, Ko-fi, and of course Open Collective. We contacted hundreds of maintainers, asking them to update their funding.yml so anyone could support them; for those who didn’t we paid maintainers directly, again through Open Collective.
We’re hoping to distribute the remaining funds this month which is why we’re launching Ecosystem Funds to the general public today.
Once again for those in the back: Sponsor the technology you depend upon, we’ll do the rest.
Find an ecosystem using our search and donate a single or recurring sponsorship. We handle everything else. We’ll direct your money (minus a 10% management fee) to maintainers, using the tools they have chosen to manage their finances. We allocate 100% of the donations in every fund with a balance of $1,000 or more, on a monthly basis. Every donation and payment is traceable through both Ecosystem Funds and Open Collective.
Donations can be made directly through funds.ecosyste.ms or, if you have an account, on Open Collective. Companies who wish to make a large donation, or start a Fund of their own, can request an Invoice from Open Source Collective — who are already an approved vendor to most large open-source-supporting organisations.
While we’re launching with nearly three hundred Funds we’re certain that we’ll have missed more than a few ecosystems around your favourite framework, tool, or package, and we’re happy to add them. Just get in touch and we’ll do some data wrangling to add it — note that we’re not going to include a Fund for just the projects you work on, that’s what GitHub Sponsors is for.
We’re also hugely aware of the limitations of our approach. We’re missing all the standards bodies, documentation projects, and foundations who support open source outside of the dependency graph. We’re also missing domain-specific Funds — there’s no climate, marine, aviation, or space-exploration based Funds to support.
To address this we’ll be building ways for communities (and corporations) to package their own Ecosystem Fund, and support it.
While building a service to support thousands of the most critical software components might be enough for some, it’s not for us. Over the coming months we’ll be building a tool to track all your open source ‘investments’, to better understand the impact your money is having on the projects you depend on most.
]]>Building an empirically complete picture of your software’s ‘deep dependencies’ can take months of investigative work and analysis to uncover projects that are looking for your support, and to get it to them.
But, fundamentally, you know what technologies you utilise… right?
Open Collective is built on Next.js, Redis, Postgres, and GraphQL. With a broad understanding of the technologies we depend upon it should be possible to hand the responsibility of getting financial support to the packages, and the people behind them to someone. Right?
Well, now you can.
Today Open Source Collective is launching Funds to support hundreds of open source Ecosystems centred on a language, framework, or package, providing you with a shortcut to supporting your dependencies, without having to invest months of your time.
In 2022 Open Source Collective and Schmidt Futures invested in building shared infrastructure for a growing community of researchers, policymakers, developers, and funders seeking to identify, secure, and sustain critical open source components.
Ecosyste.ms tracks billions of events from hundreds of sources, creating the most complete (and free) picture of open source software in the world. ecosyste.ms helped Microsoft change their approach to funding and now it’s going to change yours.
Open Source Collective is combining ecosyste.ms’ knowledge and Open Collective’s transparent fundraising and money management to create a uniquely traceable system for supporting your dependencies. You’ll see exactly where your money went, and how it has been spent. All supported by our fiscal sponsorship program and our team.
Sponsor the technology you rely on, we’ll do the rest.
No, really, we mean it. You select one or more open source ecosystems and donate a single or recurring sponsorship. We handle everything else.
We’ll direct your money (minus a 10% management fee) to the right people, using the tools projects themselves have chosen to manage their finances. We support funding through GitHub Sponsors, Thanks.dev, StackAid, LF Community Bridge, and of course Open Collective. If a project hasn’t listed a funding source, we invite maintainers to collect their donation on behalf of their community, or to let us know where they would like to do so. If they still don’t accept your donation, it will be redistributed to the fund for other projects. This process will continue monthly, supported by our amazing team.
Despite our best efforts, much of the funding for open source today goes to a small number of well-known packages and tools. We hope this announcement will go some way to alleviating that, but we call upon you, the open source maintainer, to do your part by supporting the software you depend upon too.
Today we’re announcing Ecosystem Funds with Sentry, who have committed $67,500 to the Rust, Python, Django, and Javascript Ecosystems. We’re distributing funds to 268 projects within these communities, many of which have a chosen method for accepting financial support.
Getting started
Over the coming weeks we’ll be completing our onboarding and sponsor experiences. If you can’t wait that long get in touch and we’ll work with you to sponsor the ecosystems you depend upon today.
📙 Read more about Ecosystem Funds
📗 Use Ecossyte.ms data in your next application, research, or policy project
💸 Support the development of Ecosystems, a free resource for the community