When people think of package managers they usually picture installing a library but these days package managers and their associated registries handle dozens of distinct functions. A package manager is a tool that automates the process of installing, updating, configuring, and removing software packages. In practice, modern language package managers have accumulated responsibilities far beyond this definition. ### The client **An installer:** downloads a package archive from the registry, extracts it and places it in your language’s load path so your code can import it. **An updater:** checks for newer versions of installed packages, downloads them, and replaces the old versions, either one at a time or everything at once. **A dependency resolver:** when you install a package, you install its dependencies, and their dependencies, and so on, and the resolver figures out which versions can coexist, which is NP-complete and therefore slow, difficult, and full of trade-offs. **A local cache:** stores downloaded packages on disk so subsequent installs don’t hit the network, enabling offline installs and faster builds while raising questions about cache invalidation when packages change. **A command runner:** executes a package’s CLI tool without permanently installing it by downloading the package, running the command, and cleaning up, which is useful for one-off tasks or trying tools without committing to them. **A script executor:** runs scripts defined in your manifest file, whether build, test, lint, deploy, or any custom command, providing a standard way to invoke project tasks without knowing the underlying tools. ### Project definition **A manifest format:** a file that declares your project’s dependencies with version constraints, plus metadata like name, version, description, author, license, repository URL, keywords, and entry points, serving as the source of truth for what your project needs. **A lockfile format:** records the exact versions of every direct and transitive dependency that were resolved, often with checksums to verify integrity, ensuring everyone working on the project gets identical dependencies. **Dependency types:** distinguishes between runtime dependencies, development dependencies, peer dependencies, and optional dependencies, each with different semantics for when they get installed and who’s responsible for providing them. **Overrides and resolutions:** lets you force specific versions of transitive dependencies when the default resolution doesn’t work, useful for patching security issues or working around bugs before upstream fixes them. **Workspaces:** manages multiple packages in a single repository, sharing dependencies and tooling across a monorepo while still publishing each package independently. ### The registry **An index:** lists all published versions of a package with release dates and metadata, letting you pick a specific version or see what’s available, and is the baseline data most tooling relies on. **A publishing platform:** packages your code into an archive, uploads it to the registry, and makes it available for anyone to install, handling versioning, metadata validation, and release management. **A namespace:** every package needs a unique name, and most registries use flat namespaces where names are globally unique and first-come-first-served, making short names scarce and valuable, though some support scoped names for organizations or use reverse domain notation to avoid conflicts. **A search engine:** the registry website lets you find packages by name, keyword, or category, with results sorted by downloads, recent activity, or relevance, and is often the first place developers go when looking for a library. **A documentation host:** renders READMEs on package pages, displays changelogs, and sometimes generates API documentation from source code, with some registries hosting full documentation sites separate from the package listing. **A download counter:** tracks how often each package and version gets downloaded, helping developers gauge popularity, identify abandoned projects, and make decisions about which libraries to trust. **A dependency graph API:** exposes the full tree of what depends on what, both for individual packages and across the entire registry, which security tools use to trace vulnerability impact and researchers use to study ecosystem structure. **A CDN:** distributes package downloads across edge servers worldwide, and since a popular registry handles billions of requests per week, caching, geographic distribution, and redundancy matter because outages affect millions of builds. **A binary host:** stores and serves precompiled binaries for packages that include native code, with different binaries for different operating systems, architectures, and language versions, saving users from compiling C extensions themselves. **A build farm:** some registries compile packages from source on their own infrastructure, producing binaries that users can trust weren’t tampered with on a developer’s laptop and ensuring consistent build environments. **A mirror:** organizations run internal copies of registries for reliability, speed, or compliance, since some companies need packages to come from their own infrastructure, and registries provide protocols and tooling to make this work. **A deprecation policy:** rules for marking packages as deprecated, transferring ownership of abandoned packages, or removing code entirely, addressing what happens when a maintainer disappears or a package becomes harmful and balancing immutability against the need to fix mistakes. ### Security **An authentication system:** publishers need accounts to upload packages, so registries handle signup, login, password reset, two-factor authentication, and API tokens with scopes and expiration, since account security directly affects supply chain security. **An access control system:** registries determine who can publish or modify which packages through maintainer lists, organization teams, and role-based permissions, with some supporting granular controls like publish-only tokens or requiring multiple maintainers to sign off on releases. **Trusted publishing:** some registries allow CI systems to publish packages using short-lived OIDC tokens instead of long-lived secrets, so you don’t have to store credentials in your build environment and compromised tokens expire quickly. **An audit log:** registries record who published what package, when, from what IP address, and using what credentials, useful for forensics after a compromise or just understanding how a package evolved. **Integrity verification:** registries provide checksums that detect corrupted or tampered downloads independent of signatures, so even without cryptographic verification you know you got what the registry sent. **A signing system:** registries support cryptographic signatures that verify who published a package and that it hasn’t been tampered with. Build provenance attestations can prove a package was built from specific source code in a specific environment. **A security advisory database:** registries maintain a catalog of known vulnerabilities mapped to affected package versions, so when a CVE is published they track which packages and version ranges are affected and tools can warn users. **A vulnerability scanner:** checks your installed dependencies against the advisory database and flags packages with known security issues, often running automatically during install or as a separate audit command. **A malware scanner:** registries analyze uploaded packages for malicious code before or after they’re published, where automated static analysis catches obvious patterns but sophisticated attacks often require human review. **A typosquatting detector:** registries scan for package names that look like misspellings of popular packages, which attackers register to catch developers who mistype an install command, and try to detect and block them before they cause harm. **An SBOM generator:** produces software bills of materials listing every component in your dependency tree, used for compliance, auditing, and tracking what’s actually running in production. **A security team:** registries employ people who triage vulnerability reports, investigate suspicious packages, coordinate takedowns, and respond to incidents, because automation helps but humans make the judgment calls. So what is a package manager? It depends how far you zoom out. At the surface, it’s a command that installs libraries. One level down, it’s a dependency resolver and a reproducibility tool. Further still, it’s a publishing platform, a search engine, a security operation, and part of global infrastructure. And how does all of this get funded and supported on an ongoing basis? Sponsorship programs, foundation grants, corporate backing, or just volunteer labor - it varies widely and often determines what’s possible.

We are excited to announce the Call for Participation for the Package Managers devroom at FOSDEM 2026, taking place on **Saturday, 31st January 2026** at the Université libre de Bruxelles, Belgium. **Submission deadline: 1st December 2025** ## About the Devroom 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. ## Submission Guidelines 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: * Title and subtitle of your talk * Short abstract (one paragraph) * Longer description (optional) * Desired talk length (10/25 minutes) * Links to related work, projects, or previous talks * Brief bio ## Code of Conduct All speakers and attendees are expected to follow the FOSDEM Code of Conduct. By submitting a proposal, you agree to abide by these guidelines. ## Questions? If you have any questions about the devroom or your submission, please reach out to [email protected]. 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_

Package managers are the quiet workhorses of computing. They make installing software on a machine trivial, but they have their differences, and as recent events have shown, those differences can lead to vulnerabilities and provide opportunities for attackers to disrupt public and private services alike. 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 five repositories of information about how package managers work today. In doing so we hope to identify common problems and work toward better practices: ## Package Manager Commands 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 ## Package Manager Manifest Examples 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. ## Package Manager OpenAPI Schemas 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. ## Package Managers OPML 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. ## Contributing 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 five repositories are released under CC0 1.0 Universal and accept contributions if you have corrections or additions.

Andrew Nesbitt builds tools and open datasets to support, sustain, and secure critical digital infrastructure. He's been exploring the world of open source metadata for over a decade. First with libraries.io and now with ecosyste.ms, which tracks over 12 million packages, 287 million repos, 24.5 billion dependencies, and 1.9 million maintainers. What has Andrew learned from all this, who is using this open dataset, and how does he hope others can build on top of it all? Tune in to find out.

Check out the Ecosyste.ms community on Discord - hang out with 3 other members and enjoy free voice and text chat.

**To bring the traffic down to sustainable levels and encourage efficient and responsible use we will be introducing rate limits across our services.** 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: ### What you need to do: 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: * adding `[email protected]` as a parameter to your API request, like this: * Add `mailto:[email protected]` somewhere in your user-agent request header The common pool is for everyone else. It will have less consistent response times, especially during peak periods as we serve polite requests more frequently. ### Next steps: 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

View the packages maintained by nopersonsmodules on the npmjs.org package registry, including their contributions and dependencies.

**Today Open Source Collective and ecosyste.ms are launching Funds supporting 291 Open Source Ecosystems. Unsurprisingly, we call them Ecosystem Funds.** 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. ### What are Ecosystem Funds? Using billions of data points from ecosyste.ms we’ve packaged millions of the most critical open source components into a few hundred Funds centred on a language, framework, or package, turning a process that can take months into a five minute conversation with your CTO. ### What have we been up to? 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 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. ### How does it work? 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. ### What’s next? 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. ### … Just one more thing 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.

**Today Open Source Collective and ecosyste.ms are launching Funds supporting 291 Open Source Ecosystems. Unsurprisingly, we call them Ecosystem Funds.** 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. ### What are Ecosystem Funds? Using billions of data points from ecosyste.ms we’ve packaged millions of the most critical open source components into a few hundred Funds centred on a language, framework, or package, turning a process that can take months into a five minute conversation with your CTO. ### What have we been up to? 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 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. ### How does it work? 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. ### What’s next? 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. ### … Just one more thing 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.