Rust Ecosystem Work Seeking Support

This directory lists Rust ecosystem work seeking funding from companies using Rust at scale. It includes work on the Rust compiler, Cargo, tooling, libraries, and crates published on crates.io.

The initiatives below represent active funding opportunities. Most already have at least one supporting organization and are looking for additional partners.

To discuss funding, procurement, or sharing private production feedback, come to Funding Initiative office hours. For async public discussion, join us on the commercial-network channel in Rust Project Zulip. For private discussion or to schedule private office hours, contact rust-commercial-network@rustfoundation.org.

RFEF sponsors may receive recognition, fund reporting, sponsorship coordination, and advance security disclosures when coordinated private notice is needed.

How to Help

Most listed work can be supported through the Rust Foundation Ecosystem Fund (RFEF), which directs funding to the maintainers or projects doing the work. For all Rust Project goals seeking support, see the Rust Project Goals funding page. If an organization wants to support Rust maintainers more generally, please check out the Rust Project Funding page where you can support the Rust Foundation Maintainers Fund or individual Rust project members.

Funding does not buy control over Rust technical decisions, RFC outcomes, stabilization, release timing, maintainer review, priority, or project roadmaps.

Depending on the item, support may go to an individual maintainer, a project, a fiscal host, an employer, or a foundation. Rust Project work still goes through the normal team review process, including RFCs, ACPs, implementation review, and stabilization where applicable. Project goals provide public context and coordination; they are not approval of a specific design or priority.

Use public project venues for technical feedback when possible. If confidential build data, deployment details, or production traces would be useful, contact the RCN mailbox, the relevant maintainer, or the Foundation before sharing them. Non-confidential conclusions should be summarized publicly when practical.

Named contributors and related projects are included to identify likely contacts and work owners. Inclusion does not mean the RCN, Rust Foundation, or Rust Project has endorsed a specific technical decision.

Build Performance

Wild

Wild is a Rust Innovation Lab project building a faster linker for Rust workloads. It addresses link time as a visible cost in CI or local development. Current work is aimed at large binaries, more platforms, and the missing linker features that prevent projects from trying Wild today.

The most useful sponsor input is real build data: linker timing profiles, crate graph shape, binary size, platform constraints, and failure cases. Maintainers will prioritize work that fits Wild's goals and available time.

Led by David Lattimore (@davidlattimore). Related project: Wild.

Faster Builds Roadmap

The Faster Builds Roadmap is aimed at organizations where build time affects developer wait time, CI spend, or release latency. It would fund bjorn3 (@bjorn3) for an additional day per week of Rust build performance work, complementing time already contributed through Tweede Golf.

bjorn3 would spend the funded time on the roadmap items most likely to shorten real build times.

Related: Faster Builds Roadmap, Tweede Golf.

Cargo Cross-Workspace Cache

Cargo Cross-Workspace Cache would reduce duplicate build artifacts across Cargo workspaces. It targets teams losing CI time, disk space, or local setup time to repeated Cargo artifacts. A shared cache could cut repeated CI minutes and disk use, provided it holds up against production build patterns.

Ross Sullivan (@ranger-ross) is seeking support to design and implement a first version that the Cargo team can evaluate. If accepted, support would carry the work through normal Cargo review and nightly testing. Useful data includes build times, cache hit rates, cache storage costs, workspace structure, and failure cases.

Related: Cargo Cross-Workspace Cache, Cargo.

Reusable Build Artifacts

Today, cargo check and cargo build largely duplicate work, which matters for teams that run both in local development or CI. This project aims to make build artifacts reusable across both workflows, so work done for cargo check can carry into cargo build.

Funding would give Alejandra Gonzalez (@blyxyas) time to pursue a new incremental compilation design. This work may also support Cargo Cross-Workspace Cache and other build reuse work.

Related: Incremental Compilation System, Rethought, rust-lang/rust.

Cranelift

Cranelift is an alternative Rust code generation backend. The current goal is a 2x speedup in Cranelift code generation for debug builds, reducing local compile time for teams rebuilding large Rust services many times per day.

Sponsor support would cover time for bjorn3 (@bjorn3) and Folkert de Vries (@folkertdev), through Tweede Golf, to work through the performance improvements in the project goal.

Related: Cranelift Performance Improvements, Cranelift, Tweede Golf.

Developer Experience and Tooling

cargo-nextest

cargo-nextest is a Rust test runner used in local development and CI. For teams whose Rust test suites gate releases, slow or flaky runs can delay shipping. Maintenance funding pays for the work users rely on but do not always see: releases, issue triage, contributor review, platform support, and CI-scale fixes.

Funding would buy down unpaid maintenance work for Rain (@sunshowers): releases, issue triage, contributor review, and fixes requested by users running nextest in CI. RCN members can provide feedback, test cases, or contributions through the same public channels as other users.

Related: cargo-nextest.

cargo-semver-checks

cargo-semver-checks helps Rust maintainers catch accidental SemVer breakage before publishing releases. This is especially useful for SDKs and libraries where breaking changes can disrupt downstream customers and make dependency upgrades risky.

Funding would support work to close major coverage gaps and improve PR-based workflows. Current limitations include missing type-related breaking changes, missing cross-crate analysis for re-exports, and difficulty distinguishing breakage introduced by a new PR from breakage that already exists since the last published release.

Related:

• cargo-semver-checks
• roadmap
• project goal
• goal tracking issue

Cargo Maintenance

Many Rust roadmap items need Cargo review or implementation work, including work on supply-chain policy, build reproducibility, C++ interoperability, signed crates, and sandboxed build scripts. This item funds general Cargo review and implementation time, not reserved reviewer time for funder-requested changes.

Arlo Siemsen (@arlosi) would use additional funded time for Cargo review, mentoring, implementation, and moving accepted changes through Cargo review. Cargo maintainers and Rust Project teams retain authority over review, acceptance, prioritization, and release timing.

Related: Cargo, crates.io.

C and C++ Interoperability

Many organizations adopting Rust continue to operate in mixed-language environments. Improving interoperability with existing C and C++ codebases lowers adoption barriers, simplifies migrations, and makes it easier to incrementally introduce Rust into existing systems.

Funding would support work by teor (@teor2345), folkertdev (Folkert de Vries) at Tweede Golf, and other collaborators working to identify and address high-impact interoperability gaps between Rust and C/C++.

Dozens of interoperability problem statements and use cases have already been identified with industry participants, and new implementation efforts continue to emerge from that work. Current areas of interest include support for C floating-point types such as long double, function overloading, variable arguments, smoother Rust onboarding into existing C++ projects, build and linking improvements, and other high-impact gaps.

Links:

• Interop Initiative issue tracker
• Detailed problem statements
• Interop project goals and proposals
• Interop work inventory
• C floating-point interoperability (f80, f128, c_longdouble)

Crate Namespaces

Crate namespaces would help organizations publishing related crate families, internal platform crates, SDKs, or official packages. Namespaces would let those crates live under one namespace, making ownership clearer and reducing collisions with similarly named crates.

Implementation work is underway across rustc, Cargo, and crates.io while the next project goal is still being drafted. Funding would help contributors such as Takayuki Maeda (@TaKO8Ki) continue implementing RFC 3243 and related changes. Cargo, crates.io, and rust-lang teams still decide design and policy questions through their normal processes.

Related: RFC 3243, previous project goal, Cargo, crates.io, rust-lang/rust. A new project goal has not been published yet.

Native async fn dynamic dispatch in traits

Rust supports async fn in traits, but using async methods through dyn trait objects still requires workarounds such as #[async_trait], which add allocation overhead, obscure signatures, and split the ecosystem between native async traits and boxed trait-object patterns.

Funding would support work by Santiago Pastorino (@spastorino) and Jack Huey (@jackh726) to make async trait methods usable through dynamic dispatch. The work has two parts: first, making Rust more precise about which trait methods are dyn-compatible, and second, adding native support for async dispatch through trait objects.

The goal is to reduce reliance on #[async_trait], give library authors a cleaner path for async trait APIs, and make the feature available for real-world testing on nightly before final syntax is designed.

Related: Async fn in Traits, rust-lang/rust.

Language and Compiler

Async State Machine Improvements

Rust's async implementation generates state machines behind the scenes. For async services, better state-machine generation can reduce CPU use, memory pressure, binary size, and compiler limits such as maximum query recursion depth.

Dion Dokter (@diondokter) at Tweede Golf is seeking support to continue async state machine code generation work.

Related: project goal, background, rust-lang/rust.

rustc_public

rustc_public(formerly Stable MIR) is intended to give external tools a supported way to read compiler data without depending on unstable rustc internals. That matters for static analysis, verification, GPU, compliance, and internal platform tooling.

The next project goal is still pending. Funding would help Makai (@makai410) and the Rustc Public project publish rustc_public to crates.io, expand API coverage, and improve documentation. API additions should be evaluated for general Rust tooling value, not for any one downstream project.

Related: previous project goal, rust-lang/rust. The next project goal has not been published yet.

Binary Size Reduction

A roadmap is being prepared for binary size reduction work led by Nia Espera (@nia-e) and Hexcat (@hexcatnl). The work is aimed at cases where Rust binary size affects cold-start time, memory footprint, storage pressure, firmware size, or rollout cost. Once the roadmap is published, support should focus on reductions that translate into lower cold-start time, smaller firmware or container images, and lower rollout cost for size-sensitive Rust users.

This is a funding interest area, not an approved Rust Project goal or committed outcome.

Related: rust-lang/rust. Binary-size roadmap link to be added once published.

Declarative Macro Improvements

Better declarative macros could replace some proc macros, cutting build time, dependency surface area, and supply-chain review burden. That helps where dependency review, supply-chain controls, or build-time code execution policies make proc macros expensive to adopt.

Funding would help Josh Triplett (@joshtriplett) work on declarative attributes and derive macros. It may also support related work by Oli Scherer (@oli-obk) on compile-time Rust evaluation, or "comptime". Design questions remain subject to the relevant RFC, lang/compiler team, and stabilization processes.

Related: Declarative Macro Improvements, rust-lang/rust.

Production Systems

Tokio Runtime Optimizations

Tokio is the foundation for many Rust network services and async applications. Runtime and scheduler work matters when production workloads combine network IO, timers, and compute-heavy tasks, especially where scheduler behavior affects latency, fairness, CPU use, or incident risk.

Folkert de Vries (@folkertdev) at Tweede Golf is seeking support for runtime and scheduler improvements in Tokio. Production feedback from large Tokio users would be useful, especially where scheduler behavior affects latency or incidents. Maintainers still make changes through Tokio's public design and review process.

Related: Tokio, time-based cooperative scheduling prototype, runtime optimization discussion.

rustls

rustls is a Rust Innovation Lab project that provides TLS functionality for many Rust applications and services. Production services that terminate or initiate TLS depend on timely security response, compatibility, and connection-heavy performance. Maintenance support helps pay for security response, releases, dependent-crate compatibility, and production feedback work that otherwise competes with limited maintainer time.

Dirkjan Ochtman (@djc) is seeking maintenance time for rustls security coordination, releases, contribution review, 1.0 work, async handshake performance, and production-user feedback.

Related: rustls.

Hyperium

Hyperium maintains Hyper, Tower, h2, and related networking crates used by Rust services. Teams depend on those crates for availability, protocol correctness, observability, and performance.

Sean McArthur (@seanmonstar) is seeking time for the work that keeps Hyperium crates healthy: releases, issue triage, modularization, h2 performance, buffer pooling, observability, and production-user feedback.

Related: Hyperium Roadmap.

Contact

To discuss funding, procurement, or private production feedback, come to Funding Initiative office hours. For async public discussion, join us on the commercial-network channel in Rust Project Zulip. For private discussion or to schedule private office hours, contact rust-commercial-network@rustfoundation.org.

Fully Funded

F16 Stabilization

Many machine learning, graphics, simulation, and scientific computing workloads use 16-bit floating point formats. Native f16 support would make it easier to pass f16 data between Rust, hardware APIs, and libraries that already use those values.

Sponsor support would help Folkert de Vries (@folkertdev), through Tweede Golf, continue the implementation, testing, documentation, and review work needed before f16 can be considered for stabilization. Stabilization would still be decided through the Rust Project process.

Related: F16 Stabilization, rust-lang/rust.