undirected funds RFC draft by nikomatsakis · Pull Request #6 · rust-lang/funding

nikomatsakis · 2026-02-26T01:38:46Z

Summary

The Rust Foundation Maintainer Fund (RFMF) is a joint effort by the Rust Project and the Rust Foundation to fund full-time Rust maintainers, called Maintainers in Residence. This RFC proposes how the Maintainer in Residence program should work: how candidates are selected, what's expected of them, and how the Foundation manages the relationship.

This RFC builds on the Grants team established by RFC 3919. This RFC extends the Grants team's role to also vet candidates for Maintainer in Residence positions funded through the RFMF. The Grants team identifies which areas need support and returns a prioritized recommendation to the Foundation; the Foundation makes the final hiring decision and handles contracting, compensation, and funder relations.

This RFC does not specify how much funding the RFMF has or where that funding comes from. It describes how the Project and Foundation would work together to make the best use of whatever funding is available for Maintainer in Residence positions.

Rendered.

joshtriplett · 2026-02-26T19:22:09Z

+
+Second, and likely the larger source of funding, are companies that employ developers or contributors working full-time to improve Rust. These companies already invest in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" — reviewing other people's PRs, mentoring newcomers, fixing regressions, driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy.
+
+What do funders get in return? Maintainers are always prioritizing — there are always more PRs to review, more bugs to triage, more work than time. Funders can reasonably expect that their bug reports get looked at, their PRs get reviewed, and their questions get answered. This costs the project essentially nothing: it's reprioritization within work the maintainer would do anyway. The PSF's experience after five years of its Developer in Residence program confirms that this kind of influence is normal and healthy. As one of their Developers in Residence put it when asked about sponsors influencing prioritization: *"Yes, of course, and I think that is entirely ethical."* Bloomberg, one of the PSF's sponsors, gives active feedback on how their sponsored maintainer spends time — *"they can't tell him that he MUST, but if they care about a thing, and it'll make them renew the contract for another 12 months, good to know."*


Fixing formatting.

nikomatsakis

comments from our meeting today

nikomatsakis · 2026-03-02T19:18:48Z

I've pushed a new branch that, I think, incorporates all of the feedback. I raised up a few questions to focus our discussion on those areas where I had the most uncertainty.

nikomatsakis · 2026-03-12T00:08:49Z

Pushed a commit and addressed our comments from last time.

Kobzol

The RFC looks really great, thank you Niko! I left a couple of comments, but nothing major. I would suggest having final discussions about the RFC on today's call, and then publish it at the start of the next week, we should finally ship it.

Kobzol · 2026-03-12T08:54:05Z

+
+## Application and vetting process
+
+The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. However, successful candidates must already be members of the relevant Rust team(s) with the permissions needed for the work.


Technically I'd say that only team members can apply, just to reduce the number of applications, but we likely won't have the technical means to ensure that anyway, so probably doesn't matter.

yes -- or to whom membership has been offered

Kobzol · 2026-03-12T08:58:17Z

+
+Maintainers in Residence are also expected to:
+
+* resolve time-critical issues such as newly reported bugs;


We get tens of newly reported bugs daily, so this seems a bit broad. Maybe something like "newly reported urgent bugs"?

Suggested change

* resolve time-critical issues such as newly reported bugs;

* resolve time-critical issues such as urgent bugs;

Co-authored-by: Jakub Beránek <berykubik@gmail.com>

nikomatsakis · 2026-03-12T18:54:08Z

+
+## Application and vetting process
+
+The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. However, successful candidates must already be members of the relevant Rust team(s) with the permissions needed for the work.


yes -- or to whom membership has been offered

Co-authored-by: Tyler Mandry <tmandry@gmail.com>

nikomatsakis · 2026-03-12T21:40:55Z

Pushed more edits.

Thanks @tmandry, good suggestion, applied.

tmandry

Thank you Niko for driving this. I think we are very close to the RFC we should open on the repo.

tmandry · 2026-03-12T22:09:05Z

+
+## What Maintainers in Residence do
+
+Maintainers in Residence split their time between team priorities and individual priorities of their own choosing within their area of focus. The exact balance varies depending on the individual, their experience, and the needs of the team — the important thing is that both team-directed and self-directed work are expected. This is about "team-directed vs. self-directed," not "maintenance vs. features." The PSF's experience after nearly five years confirms that focusing purely on team-directed needs and multiplicative maintenance can be very draining; giving time for self-directed projects "made all the difference" in satisfaction.


This is about "team-directed vs. self-directed," not "maintenance vs. features."

I'm trying to understand the purpose of this sentence and what it implies about feature work. Team-directed and self-directed work could both involve both maintenance and feature work, and it's not clear to me that the RFC should rule out either one.

At the same time, we should help make sure sponsors know what they are getting for their money, so an emphasis on maintenance (perhaps broadly interpreted) does make sense.

tmandry · 2026-03-12T22:29:06Z

+
+The program's evolution taught us several lessons we've incorporated into this RFC. First, pure maintenance work becomes draining over time. The first Developer in Residence started doing only reviews, backports, and CI, and found that after a year or two, "there's not much joy in that." Allowing feature work alongside maintenance "made all the difference." We've reflected this in the RFMF design: Maintainers in Residence split their time roughly 50/50 between team priorities and individual priorities of their choosing, rather than being assigned purely to maintenance.
+
+Second, sponsors attach to people, not positions. In practice, a sponsor funding a position filled by a particular person will want to continue sponsoring that person specifically if they're happy with the work, rather than funding an abstract role. This has implications for how the Foundation thinks about sponsor relationships: sponsors care about outcomes and the people producing them.


It seems like this paragraph can be taken out in favor of the next one.

Co-authored-by: Josh Triplett <josh@joshtriplett.org>

remove the 50/50 description, too specific.

Kobzol

Thanks a lot, Niko! We'll continue in an actual RFC.

undirected funds RFC draft

5b87861

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

Kobzol mentioned this pull request Feb 26, 2026

Grants team and 2026 grants program rust-lang/rfcs#3919

Draft

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Feb 26, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

nikomatsakis commented Feb 26, 2026

View reviewed changes

Kobzol reviewed Feb 28, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

Comment thread rfcs/undirected-funds-rfc.md Outdated

Comment thread rfcs/undirected-funds-rfc.md Outdated

Comment thread rfcs/undirected-funds-rfc.md Outdated

refactor: draft 2

5e3f9e0

joshtriplett reviewed Mar 5, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Mar 5, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

joshtriplett reviewed Mar 5, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

nikomatsakis commented Mar 11, 2026

View reviewed changes

refact: address feedback from last week

c270afd

Kobzol reviewed Mar 12, 2026

View reviewed changes

Apply suggestions from code review

84cba63

Co-authored-by: Jakub Beránek <berykubik@gmail.com>

nikomatsakis commented Mar 12, 2026

View reviewed changes

fix: updates based on our discussion today

772d81a

tmandry reviewed Mar 12, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

nikomatsakis and others added 2 commits March 12, 2026 17:30

fix: further tweaks

942a181

Update rfcs/undirected-funds-rfc.md

ad25750

Co-authored-by: Tyler Mandry <tmandry@gmail.com>

tmandry reviewed Mar 12, 2026

View reviewed changes

joshtriplett reviewed Mar 14, 2026

View reviewed changes

Comment thread rfcs/undirected-funds-rfc.md Outdated

nikomatsakis and others added 11 commits March 16, 2026 11:17

Update rfcs/undirected-funds-rfc.md

919f357

Co-authored-by: Josh Triplett <josh@joshtriplett.org>

rework axioms in response to tmandry's points

8e77468

justify and clarify developer time split

9ef2900

remove the 50/50 description, too specific.

adjust discussion of area selection

6a7c1de

clarify team membership requirements

cdce1bd

be more consistent with pluralization

d92cbb0

clarify mir target

62e060b

clarify reporting requirements

5225715

clarify team membership requirements

6fb2d99

rename sponsor benefit section

34153cc

clarify contract renewal

d12c188

Kobzol approved these changes Mar 16, 2026

View reviewed changes

Kobzol merged commit 420a754 into rust-lang:main Mar 16, 2026


		Second, and likely the larger source of funding, are companies that employ developers or contributors working full-time to improve Rust. These companies already invest in Rust development, but their contributors' work still needs to be reviewed and landed by experienced maintainers. The incentive structures at most companies don't reward "general maintenance" — reviewing other people's PRs, mentoring newcomers, fixing regressions, driving cross-cutting refactors. These activities don't advance any single company's goals, so they're hard to justify in a performance review and vulnerable to restructuring when priorities shift. Sponsoring the maintainer fund is a way for these companies to ensure the maintenance layer their contributors depend on stays healthy.

		What do funders get in return? Maintainers are always prioritizing — there are always more PRs to review, more bugs to triage, more work than time. Funders can reasonably expect that their bug reports get looked at, their PRs get reviewed, and their questions get answered. This costs the project essentially nothing: it's reprioritization within work the maintainer would do anyway. The PSF's experience after five years of its Developer in Residence program confirms that this kind of influence is normal and healthy. As one of their Developers in Residence put it when asked about sponsors influencing prioritization: "Yes, of course, and I think that is entirely ethical." Bloomberg, one of the PSF's sponsors, gives active feedback on how their sponsored maintainer spends time — "they can't tell him that he MUST, but if they care about a thing, and it'll make them renew the contract for another 12 months, good to know."


		## Application and vetting process

		The process of contracting a new Maintainer in Residence begins with an open call for applications. Anyone can apply — broad applications help surface needs and candidates the Funding team might not have identified on its own. However, successful candidates must already be members of the relevant Rust team(s) with the permissions needed for the work.


		Maintainers in Residence are also expected to:

		* resolve time-critical issues such as newly reported bugs;

	* resolve time-critical issues such as newly reported bugs;
	* resolve time-critical issues such as urgent bugs;


		## What Maintainers in Residence do

		Maintainers in Residence split their time between team priorities and individual priorities of their own choosing within their area of focus. The exact balance varies depending on the individual, their experience, and the needs of the team — the important thing is that both team-directed and self-directed work are expected. This is about "team-directed vs. self-directed," not "maintenance vs. features." The PSF's experience after nearly five years confirms that focusing purely on team-directed needs and multiplicative maintenance can be very draining; giving time for self-directed projects "made all the difference" in satisfaction.


		The program's evolution taught us several lessons we've incorporated into this RFC. First, pure maintenance work becomes draining over time. The first Developer in Residence started doing only reviews, backports, and CI, and found that after a year or two, "there's not much joy in that." Allowing feature work alongside maintenance "made all the difference." We've reflected this in the RFMF design: Maintainers in Residence split their time roughly 50/50 between team priorities and individual priorities of their choosing, rather than being assigned purely to maintenance.

		Second, sponsors attach to people, not positions. In practice, a sponsor funding a position filled by a particular person will want to continue sponsoring that person specifically if they're happy with the work, rather than funding an abstract role. This has implications for how the Foundation thinks about sponsor relationships: sponsors care about outcomes and the people producing them.

Conversation

nikomatsakis commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nikomatsakis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nikomatsakis commented Mar 2, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nikomatsakis commented Mar 12, 2026

Uh oh!

Kobzol left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nikomatsakis commented Mar 12, 2026

nikomatsakis commented Feb 26, 2026 •

edited

Loading