Rust Commercial Network (RCN)

Where Rust users, businesses, and communities work together to make Rust easier to adopt and maintain.

The Rust Commercial Network (RCN) is a Rust Foundation group for people and organizations using Rust in professional settings. Members compare notes on adoption blockers, improve Rust supply chain health, and support the basic tooling, libraries, and maintenance work that make Rust dependable in production.

Join: fill out the membership application.

Members: see the current RCN member list.

Fund the Rust Ecosystem: see Fund the Rust Ecosystem.

Discuss: use the RCN channel in the Rust Project Zulip.

Calendar: see the RCN meeting calendar.

Rust Foundation: see the RCN page on the Rust Foundation site.

Overview

The RCN is open to Rust users of all sizes: individual commercial users, consultants, startups, small businesses, larger companies, academic users, organizations, Rust Foundation Members, Rust Advocates, and members of the Rust Project. The RCN supports industry consortiums, interest groups, working groups, and other initiatives, with review from the RCN Steering Committee.

The RCN is separate from the Rust Project's developing Rust Society, although there may be some overlap over time.

Membership in the RCN is free.

The RCN works to:

Identify Rust adoption and maintenance problems shared by production users
Form consortiums, working groups, and interest groups around industry-specific or ecosystem-wide needs
Help members contribute time, funding, testing, documentation, and maintainer support
Share findings with the Rust Project, ecosystem maintainers, and the Rust Foundation

What Members Do

Meet regularly
Discuss topics that matter to production Rust users
Promote industry-specific adoption of Rust
Meet in person when possible, including at Rust Foundation events such as the Member Summit
Work with the Rust Project and ecosystem maintainers to identify and resolve issues that affect commercial and organizational use, including tooling gaps, crate reliability, maintenance bottlenecks, and adoption papercuts
- Members may contribute engineering time, funding, testing, maintainer support, documentation work, contributions to the Rust Foundation Maintainer's Fund, or other help

RCN may produce:

Best practice guides and reference architectures
Adoption playbooks
Feedback summaries for the Rust Project
Gap analyses for tooling, libraries, documentation, and maintenance capacity
Prioritized lists of papercuts and reliability issues affecting production users
Recommendations to improve core tooling, widely used libraries, crate reliability, long-term maintenance, and Rust supply chain health

*Individual issues can be brought up to the Project independent of the RCN. The RCN aims to identify recurring or broadly shared issues, including smaller papercuts that add up to adoption, reliability, or maintenance problems across organizations.

RCN Initiatives: Interest Groups, Working Groups, and Consortiums

RCN members can propose initiatives focused on shared adoption blockers, ecosystem maintenance, or industry-specific needs. These initiatives may be formally organized as interest groups, working groups, or consortiums which can produce guides, reports, recommendations, or other outputs for the Rust community.

To propose an initiative, file an application using the GitHub Issue template. See RCN Initiatives: Interest Groups, Working Groups, and Consortiums for operations, Steering Committee scope, voting rights, and withdrawal details.

Meetings and Communication

The RCN hosts public monthly meeting(s)* to discuss topics related to production Rust users. The meetings take place on Google Meet. The RCN may use Chatham House Rule when meetings cover sensitive topics.

Public discussion happens in the RCN channel in the Rust Project Zulip. See Meetings for meeting policy, note-taking, and communication details.

*The RCN will determine the cadence and number of meetings per year.

Member Definitions and Governance

RCN membership is free. See Membership for member definitions, including Rust Foundation Members, Commercial/Organizational Members, Rust Advocates, Rust Project Members, and RCN Initiative Members.

The Rust Foundation maintains the RCN with support from the RCN Steering Committee. See Governance for Steering Committee duties, composition, selection, terms, vacancies, and eligibility.

Policies

RCN participants are expected to follow the Rust Foundation Code of Conduct, the Rust Foundation anti-trust policy, and the RCN Conflict of Interest Policy. Additional Rust Foundation policies are available on the Rust Foundation website.

Community Events

The Rust Foundation Member Summit, attached to RustConf, may provide one place for RCN members, Rust Foundation members, Rust Foundation Board Members, and Rust Project members to meet in person.

Next Steps

Apply to join the RCN
Propose an initiative
Fund the Rust Ecosystem
Join the RCN channel in the Rust Project Zulip

Contributing

See CONTRIBUTING.md.

Members

The Rust Commercial Network includes organizations and individuals working together to make Rust easier to adopt and maintain.

This page is generated from the RCN Membership GitHub Project during the website deployment.

Organizations

Member Names

Fund the Rust Ecosystem

Does your company depend on Rust?

The Funding Initiative is for RCN members who want to fund maintainer time for both directed work and maintenance in the Rust ecosystem.

If your organization has budget, or you need help making the case for one, come to Funding Initiative office hours. Office hours are for sponsors and potential sponsors, not for projects seeking funding.

Small and large contributions are welcome. If you cannot discuss something publicly, email rust-commercial-network@rustfoundation.org and we can schedule a private conversation. For async public discussion, use the commercial-network channel in Rust Project Zulip.

Funding Directory

The Funding Directory lists open funding opportunities, including project work, ongoing maintenance, reviews, and project support.

Office Hours

Funding Initiative office hours are for routing a budget, preparing an internal funding pitch, and working through sponsorship logistics.

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
❌ Not funded	❌ Not funded	❌ Not funded	❌ Not funded

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.

Q3 '26	Q4 '26	Q1 '27
✅ Funded	✅ Funded	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
✅ Funded	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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:

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27
❌ Not funded	❌ Not funded	❌ Not funded

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26
✅ Funded	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
❌ Not funded	❌ Not funded	❌ Not funded	❌ Not funded

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
❌ Not funded	❌ Not funded	❌ Not funded	❌ Not funded

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
❌ Not funded	❌ Not funded	❌ Not funded	❌ Not funded

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
✅ Funded	❌ Not funded	❌ Not funded	❌ Not funded

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q3 '26	Q4 '26	Q1 '27	Q2 '27
⚠️ Partial	⚠️ Partial	⚠️ Partial	⚠️ Partial

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.

Q1 '26	Q2 '26
✅ Funded	✅ Funded

Funding Initiative Office Hours

Funding Initiative office hours are for RCN members working on Rust ecosystem funding from the sponsor side.

They are for sponsors and potential sponsors, not for projects seeking funding.

Use office hours to:

Match a budget to funding opportunities
Prepare an internal funding pitch
Work through sponsorship logistics
Ask about items in the Funding Directory

The first office hours are scheduled for July 8, 2026 at 8:00 AM Pacific on the RCN calendar. Scheduling and agenda discussion happen in the Funding Initiative office hours Zulip thread.

For async public discussion outside office hours, 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.

Network Services Working Group

Every company building Rust network services hits the same walls: fragmented ecosystem choices, undocumented best practices locked inside individual organizations, and library gaps that no single team can justify fixing alone. This working group brings those teams together to publish shared guidance, prioritize ecosystem gaps, and coordinate fixes.

Scope: HTTP servers, proxies, gRPC services, async service frameworks, event processors, and the infrastructure around them. If your team runs Rust in production for anything involving network I/O and async runtimes, this is for you.

Status

The working group held its kickoff meeting in June 2026 and is now scheduling regular meetings. Async discussion is ongoing in the Zulip thread. We're looking for members to help shape the agenda and first deliverables.

Goals

Publish reference network stacks for common use cases (HTTP services, gRPC, high-throughput proxies, event processors), so new teams don't have to rediscover what large organizations already know.
Surface and prioritize ecosystem gaps across member organizations, turning individual frustrations into a shared backlog with real resources behind it.
Coordinate funding and engineering contributions to close those gaps in upstream crates, working with existing maintainers.

Get Involved

Participation is open to everyone, including non-RCN members.

Join the conversation: follow the Network Services WG topic on Zulip
Join the next meeting: see details that follow
See what we discussed last time: check the past meeting notes that follow

Meetings are roughly monthly, about an hour. Between meetings, coordination happens on Zulip.

Calendar

See the RCN meeting calendar for upcoming meetings.

Next Meeting

July 9, 2026

Time zone	Time
Pacific (PT)	8:00 AM
Eastern (ET)	11:00 AM
UTC	15:00
Central European (CEST)	5:00 PM
Japan (JST)	12:00 AM (July 10)
Australia Eastern (AEST)	1:00 AM (July 10)

Calendar link · Notes and agenda

Discussion: Network Services WG meeting schedule on Zulip

Past Meeting Notes

2025-06-09 Kickoff

RCN Membership

Membership in the RCN is free.

You do not need to work for a Rust Foundation member company to join discussions or propose work.

Member Definitions

Rust Foundation Member

Individual representing a company that is a member of the Rust Foundation in good standing.

Commercial/Organizational Member

A Commercial/Organizational Member is an individual who uses or evaluates Rust for work, including commercial, organizational, consulting, education, startup, small business, or independent professional work. These members may use Rust in production, contribute to Rust projects, or build Rust-based products or services.

Rust Advocate

Rust Advocates are experienced Rust practitioners who work in areas such as Robotics, Automotive, Public Sector, and cloud native. These advocates have been sourced from participation in RustConf and other Rust Foundation initiatives. They may or may not be Rust Project members.

Rust Project Member

Rust Project Members are individuals on a Rust Team who make significant contributions to the development and maintenance of the Rust programming language and its associated tools.

RCN Initiative Member

An RCN Initiative Member is an individual who is an active member of an RCN-affiliated consortium, working group, interest group, or other RCN initiative as determined by that initiative's own membership criteria and processes. RCN Initiative Members are recognized as RCN participants and may attend RCN meetings, contribute to discussions, and access RCN communication channels.

RCN Initiative Members may vote on RCN matters that directly affect the RCN initiative in which they hold membership, including but not limited to: policies governing RCN initiative operations, changes to the relationship between the RCN and its consortiums, working groups, or interest groups, and amendments to this charter that alter the rights or obligations of RCN initiatives.

RCN Initiative Members do not vote in RCN-wide elections such as Steering Committee seats unless they independently qualify under another RCN member definition.

For the purposes of determining good standing, RCN Initiative Members must meet the membership requirements of their respective RCN initiative. Attendance at RCN-level meetings is not required for RCN Initiative Members to maintain good standing.

RCN Governance

The RCN is a volunteer-driven community maintained by the Rust Foundation. It consists of the membership, a Steering Committee, and the initiatives (consortiums, working groups, interest groups, etc.) that the Steering Committee approves and reviews. You can be a member of the RCN without joining an initiative.

RCN Steering Committee

Purpose and Duties

The RCN Steering Committee:

Represents the RCN to the Rust Foundation Board, conferences, and media
Shares user needs with the Rust Project and works with Project members on possible solutions. The SC does not speak on behalf of any initiative to the Rust Project or external bodies without that initiative's explicit consent.
Reviews and votes on proposed RCN initiatives
Helps RCN initiatives establish an appropriate organizational structure (a consortium, a working group, an interest group, etc.) and develop respective governance documents
Develops policies and procedures consistent with this charter
Keeps RCN work documented and public

Composition and Selection

RCN members in good standing vote on RCN Steering Committee members. A member in good standing has attended at least 2 RCN meetings and is officially listed on the RCN GitHub Repo as a RCN member. For a listing of Rust Foundation Members visit https://rustfoundation.org/members/.

The RCN Steering Committee Consists Of

No more than seven and no less than five representatives from Platinum (1), Gold (1), Silver (2), and Associate (1) Rust Foundation members. There cannot be two Steering Committee Members from one company.
The Rust Foundation will have a seat on the Steering Committee in an advisory capacity.
The Rust Project will have a seat on the Steering Committee in an advisory capacity.

Terms and Termination

RCN SC Members serve approximately two-year terms, with staggered terms initially.
RCN SC Membership ceases if a member resigns, is removed, or changes employment away from a Rust Foundation member. A super-majority vote can remove members not fulfilling their duties or complying with RCN policies.

Vacancies and Alternates

Vacancies that would put steering committee membership below five (5) are filled by election or invitation.

Eligibility and Criteria

Members must be employees of Rust Foundation Membership companies in good standing.
Only one representative from the same organization may serve at a time.

Conflict of Interest Policy

The aim of this policy is to ensure that decisions made by Members of the Rust Commercial Network ("RCN") created and hosted by the Rust Foundation ("Foundation"), are in the best interests of the RCN, the wider language ecosystem, and the public, rather than influenced by personal or organisational interests. This policy serves to define the term "conflict of interest," to assist members of the RCN, and to disclose such conflicts, and to minimize the impact of such conflicts on the actions of the Foundation whenever possible. Collectively, this policy will refer to members of the RCN as "Covered Members."

Conflict of Interest Defined

A "conflict of interest" is any transaction or relationship that presents, or may present, a conflict between a Covered Member's obligations to Foundation and their personal, business, or other interests.

Disclosure

Foundation and RCN Members recognize that conflicts of interest are not uncommon, and that not all conflicts of interest are necessarily harmful to the Foundation. However, RCN membership requires full disclosure of all actual and potential conflicts of interest. Each Covered Member shall disclose any and all facts that may be construed as a conflict of interest upon joining the RCN, at the start of any meeting where relevant matters are discussed, and as soon as circumstances change.

Process and Remedy

The Foundation and RCN Steering Committee will determine whether or not a conflict of interest exists, and whether or not such conflict materially and adversely affects the interests of the Foundation. A Covered Member whose potential conflict is under review may not debate, vote, or otherwise participate in such determination. If the Foundation and RCN Steering Committee determine that an actual or potential conflict of interest exists, the Board shall also determine an appropriate remedy. Such a remedy may include, for example, the recusal of the conflicted Covered Member from participating in certain matters pending before the RCN Steering Committee or other Foundation body.

Delegation

The Foundation and RCN Steering Committee may delegate its authority to review and remedy potential conflicts of interest to a committee. Only disinterested members of the committee may participate in any such review. The committee shall inform the Foundation and RCN Steering Committee of its determination and recommended action. The Foundation and RCN Steering Committee shall retain the right to modify or reverse such determination and action, and shall retain the ultimate enforcement authority with respect to the interpretation and application of this policy.

Acceptance

Participation in the Network constitutes acceptance of this policy and agreement to comply with its requirements.

RCN Meetings

RCN meetings may cover sensitive adoption, production, or ecosystem concerns. To support candid discussion, the RCN may use Chatham House Rule. The RCN will host public monthly meeting(s)* on Google Meet to discuss topics related to production Rust users.

*The RCN will determine the cadence and number of meetings per year.

Chatham House Rule

Chatham House Rule means participants may share what was said, but may not identify who said it.

When Chatham House Rule applies, participants may not record, transcribe, or use AI bots to capture the meeting.

Meeting Option

If Chatham House Rule is not needed for a meeting, the RCN may allow recording or transcription with the group's agreement.

Notetaker Role

Each meeting will have a notetaker from the Rust Foundation or the attendee group. See the notetaker role doc for more information.

Communication

The RCN uses a channel in the Rust Project Zulip for async discussion and meeting topics. Participants are encouraged to create public discussion threads when possible. Zulip is a public forum with members of the Rust Project, guests of the Project, end users, and Rust Foundation staff; threads are publicly accessible. Private channels may be necessary to discuss sensitive topics, but the preference is to keep conversations open, matching how the Project operates.

RCN Initiatives: Interest Groups, Working Groups, and Consortiums

RCN members can propose initiatives to the Steering Committee. These initiatives have a clear focus, report findings back to the Steering Committee, and follow the guidelines below. The initiatives can be formally organized as interest groups, working groups, consortiums, or other collaborative forms.

To propose an initiative, file an application using the GitHub Issue template.

Areas of Work

RCN members may propose an initiative for a specific Rust adoption or ecosystem maintenance topic. Proposed areas include:

Identifying shared challenges in Rust adoption, crate maintenance, supply chain reliability, and ecosystem maintenance
Creating high-level frameworks or templates to help others adopt Rust
Identifying basic tooling and library needs that affect production users
Highlighting projects that are not in the Rust Innovation Lab (RIL) but need more visibility, funding, or engineering time

Operations

Each initiative defines and administers its own organizational form, membership criteria, tiers, and processes. Membership in an RCN initiative does not necessarily require RCN membership.

Membership in the RCN and membership in an RCN initiative are independent. RCN membership does not confer membership, standing, or participation rights in any initiative.

Steering Committee Scope

The RCN Steering Committee reviews initiatives to make sure their work fits the RCN mission. The SC helps initiatives establish the appropriate organizational form (interest group, working group, consortium, etc.) and draft the charters and other governance documents that define how they operate. The SC does not have authority over an initiative's internal processes, membership decisions, leadership selection, technical direction, or public communications.

To be clear, "fits the RCN mission" means that the initiative operates within the scope of Rust adoption by commercial, industrial, or organizational users. It does not authorize the SC to require changes to an initiative's scope, priorities, deliverables, publication schedule, or processes in order to remain affiliated with the RCN.

Voting Rights

Only RCN members in good standing may vote in RCN-level elections. Only initiative members may vote in initiative-level decisions, as defined by that initiative's own governance.

Existing Initiatives

Initiatives (consortiums, interest groups, or working groups) that predate the RCN or that maintain their own governance structures retain full authority over their technical outputs, publication decisions, and operational processes. The SC may not condition continued RCN affiliation on changes to an initiative's existing governance, scope, processes, or external relationships, including direct relationships with the Rust Project, standards bodies, or other organizations.

Withdrawal

An RCN-affiliated initiative may withdraw from the RCN at any time by written notice from that initiative's leadership to the RCN Steering Committee. Upon withdrawal, the initiative retains its existing governance structures, membership, repositories, branding, and intellectual property. Withdrawal does not require SC approval. Former RCN-affiliated initiatives are welcome to seek re-affiliation in the future.

Meeting Notetaker Role

Thank you for taking notes for a session! The following are the steps you will follow.

Reminder that we follow the RCN-wide agreed meeting policies. Please refer to the Meetings doc.

Take meeting notes live in a Google Docs document

Start with the right meeting notes template:

During the meeting you'll take meeting minutes of participants' discussion in a Google Docs document that will be shared as the meeting begins.

You'll add yourself as Notetaker for the meeting in the Google Doc.

Try to annotate live sections that are [info], [decision], and [todo]

We use an annotation system to note those sections which are [info], [decision], or [todo] so that the meeting minutes can be easily searched.

So in the meeting notes try to annotate live those points which come up that could fall into one of those categories.

Feel free to speak up during the meeting to clarify if something has risen to the level of a [decision] or [todo] if unclear.

Submit the meeting minutes to the repo

Following the meeting you will select all the contents of the Google Doc, right click, and then click Copy as Markdown on the menu that pops up. You have to make sure Markdown is enabled for the document. Enable it from Tools > Preferences by checking Enable Markdown.

Fork this repository if not done yet.

Create a new branch on your fork, open the minutes.md for the meeting you've taken minutes for, and paste the contents.

Inserting annotation key

Below the title of the meeting, date and time insert the following annotation key:

| Search Key  | Description          |
|-------------|----------------------|
| [todo]      | Action Item          |
| [decision]  | Something decided on |
| [important] | Key information      |

(Do not place in a code block in minutes.md, but placed in one here to make copying easier)

Open up a pull request from your feature branch into the main repo.

Monitor till merged

Monitor for any reviews that come through for suggestions on changes and respond back and/or update as necessary.

You're done!

Thanks again for taking on the notetaker role for the meeting.

# RCN Meeting on \<date\> @ \<time\>

| Search Key | Description |
| :---- | :---- |
| \[todo\] | Action Item |
| \[decision\] | Something decided on |
| \[important\] | Key information |

## Agenda

1.

## Check-in area

**Please add your name, and an emoji that describes your day.**

*

**Notetaker:**

*

For tips on how we take notes in the RCN, please see the [Meeting Notetaker Role](https://github.com/Rust-Commercial-Network/rcn/blob/main/docs/notetaker-role.md) doc.

## Housekeeping section

*

## Tasks

*

## Meeting Minutes

*

## Material

Any material to read before the meeting should be included here.

*

# \<Foo\> RCN Initiative Meeting on \<date\> @ \<time\>

| Search Key | Description |
| :---- | :---- |
| \[todo\] | Action Item |
| \[decision\] | Something decided on |
| \[important\] | Key information |

## Agenda

1.

## Check-in area

**Please add your name, and an emoji that describes your day.**

*

**Notetaker:**

*

For tips on how we take notes in the RCN, please see the [Meeting Notetaker Role](https://github.com/Rust-Commercial-Network/rcn/blob/main/docs/notetaker-role.md) doc.

## Housekeeping section

*

## Tasks

*

## Meeting Minutes

*

## Material

Any material to read before the meeting should be included here.

*