Propose the Rust Foundation Maintainer fund

[nikomatsakis]

View all comments

Important

When responding to RFCs, try to use inline review comments (it is possible to leave an inline review comment for the entire file at the top) instead of direct comments for normal comments and keep normal comments for procedural matters like starting FCPs.

This keeps the discussion more organized.

This RFC defines the relationship between the Rust Foundation Maintainer Fund (RFMF) and the open-source Rust project. The RFMF is a dedicated fund used to support Rust maintenance: open-ended, multiplicative work that improves Rust and its codebase and makes it more accessible.

The Leadership Council has a Project Priorities budget, which is used to fund various initiatives, such as travel grants or program management. RFMF funds will be directed to this budget, but they will be earmarked for activities that direct funding to individual maintainers. This includes the existing program management program and would include the proposed Project Grants Program (RFC 3919), which provides modest stipends to recognize and support existing contributors. It will also include a third program, the Maintainer in Residence program, proposed by this RFC.

The Maintainer in Residence program is dedicated to hiring long-term maintainers and funding their maintenance work in full. Maintainers' in Residence time is split between priorities guided by the teams they are supporting and priorities of their own choosing within the project.

Selecting Maintainers in Residence is a collaboration between the Foundation and a "Funding team" appointed by the Leadership Council. This Funding team will weigh the set of applications against the project's needs and priorities.

The Funding team is additionally charged with ensuring the program's overall success. When sponsors contribute undirected funding, they are investing in the Rust project as a whole — and the project should meet them in good faith. Project teams receiving support from the program are expected to help the Funding team manage sponsor relations, e.g., by meeting with sponsors or providing other reasonable sponsor benefits.

This RFC was jointly written by the RFMF Design Committee.

Rendered

[clarfonthey]

Will have more direct comments later, but one big pressing issue IMHO is that this RFC doesn't really address an obvious issue with the framework: why would a company give into a general pool which does not influence the direction of the language, rather than hire maintainers to work for them where they can?

Obviously, this is a difficult problem to solve, but an obvious result of a system where we can no longer trust major tech companies to be good-faith actors.

The following scenario is extremely likely to occur:

• A Rust maintainer is discharged from their current position, for one reason or another.
• Knowing that they are a maintainer, a company hires them to continue working without many strings attached…
• Minus the potential strings that could eventually crop up, of course

Note that this kind of position could even be more favourable to maintainers, because despite the additional conditions to be met, these companies could likely provide more compensation and benefits than the RFMF could provide, alongside benefits which are essentially required for US-based folks specifically like health insurance.

I'm not saying that this is an easy problem to solve, or that anyone is making the wrong choice by choosing to accept a position one way or another. And I don't think that an opportunity like this is necessarily bad. I'm just saying that it feels like something that should be taken as a serious threat to the integrity of the project, especially as it tries to move toward a model where it has more independence than it currently has from these companies.

What should be done to ensure that independence, rather than relying on companies to, in good faith, pay the Foundation to hire people that they could hire instead?

[Kobzol]

I'm just saying that it feels like something that should be taken as a serious threat to the integrity of the project, especially as it tries to move toward a model where it has more independence than it currently has from these companies.

What exactly do you see as the threat to the integrity of the Project? If we had a lot of companies hiring Rust maintainers, that would be great, actually, IMO. We have the opposite problem, companies are letting go of Rust maintainers left and right, which is why we are trying to establish this fund.

The RFC does actually mention some benefits to companies sponsoring RFMF. Having meetings with the Leadership Council and/or team leads, or having a direct channel to report critical bugs. Plus they let the Project choose (who knows best) who is the best maintainer to get the job done - most companies don't actually care about who works on area X, they just want to see area X (e.g. async, Rust for Linux, etc.) being improved to unblock their use-case.

The RFC also mentions the possibility of establishing a "maintainer tax", where companies funding specific feature work in other areas (such as a potential funding program for the Project Goals) would have to give a certain % of the funding to the unrestricted maintainer fund to ensure that reviews and refactorings are able to make progress.

[clarfonthey]

I should clarify this a bit better: not establishing an effective maintainer's fund is the threat to integrity, and companies being incintivised to hire over contribute to the fund is a threat to it being effective, even though that's not what they're doing at the moment. (Across the board, the tech industry is just laying everyone off, so, it's expected that this would include Rust maintainers too.)

A "maintainer's tax" would be one valid solution, but I think it's worth calling out the problem at least too. Because while hiring people to work on the project is generally a big win, the foundation being able to do it while retaining independent control is better.

[joshtriplett]

why would a company give into a general pool which does not influence the direction of the language, rather than hire maintainers to work for them where they can?

Many, many reasons. They may want to share the load with others. They may want to generally support "what the project needs" without having to research what that might be or provide management for it. They may want to support it out of a broader/different budget, so that it isn't the responsibility of people within one specific team in a company. They may find it easier to justify, and more insulated from people being as readily repurposed for internal matters. They may want to be in good company with other reputable companies which also do the same.

[clarfonthey]

I think you miss my point by answering the question directly: the point isn't, why would a company who wants to help out the Rust project choose this option over the selfish/coercive option, and more, how do we find a way to avoid companies from being selfish/coercive at all to preserve the independence of the project in its decisionmaking and support maintainers at the same time?

Again, I don't think that anyone hired to maintain Rust has had ulterior motives or coercion so far, and for reasons listed, don't think anyone will be hired in the future to do so either. But I think that options like having a "maintainer's tax" on all dedicated sponsorships to ensure that companies will still support the RFMF even if they want more control over the project is a way to ensure that, even for an industry that is willing to play dirty, there are maintainers who are both funded and allowed to remain independent.

Like, it cannot be overstated how much companies are willing to spend more money to ensure they have power and workers have none. And that could mean that a lot of money is put into specific projects for the foundation and not in the RFMF. How do we forge a path to help avoid this situation happening?

[nikomatsakis]

In any case, I'm kind of missing the "actionable suggestion" here -- is there an edit you'd like to see, @clarfonthey? Are you concerned that we should not do this program at all? I'm not sure.

[nikomatsakis]

Ah, re-reading, I see I kind of missed the point. You're concerned that companies will hire too many maintainers? As I wrote above, I wish that were the case.

In any case, from your comments, I got the impression (perhaps false) that you view the influence of companies participating in open source as 'pernicious'. To me it is desired end state!

I want companies to come and be active participants in the community. I want them to talk about their needs and then pay their own employees to come and meet those needs and to pitch in and do the general maintenance.

The reality though is that this is not often the case-- most companies are customers, they just want to use Rust -- and that's fine and normal, they have their own goals.

And even those companies that do hire people to pitch in and make Rust better are going to want those people to demonstrate that they did so. They aren't really going to incentivize open-ended maintenance. So we're trying to provide them a venue.

[nikomatsakis]

I think there's another concern which is like -- why would they contribute even to this fund? That's of course what the sponsor benefits are meant to address, but I think the reality is that we're also going to need some directed funding (with overhead) to make that really work. That's Future Work, though.

[nikomatsakis]

I'm inclined to resolve this conversation, as I feel like you're questioning the basic existence of the fund and I'm not really inclined to debate it, but I'm going to hold off until I'm sure I understand. Is there a specific kind of change you think we could make here to address this concern and, if so, what would it be?

[nikomatsakis]

I see you resolved this @clarfonthey but I'm going to unresolve it briefly. I was thinking that I'd like to at minimum include your points in a FAQ or some similar section, my preference is that the RFC includes the thoughts that were raised on the thread. I'm going to take a crack at summarizing them to be sure I'm following, ok?

[teor2345]

Some minor wording change suggestions

View changes since this review

[clarfonthey]

Not sure if this is the right place to clarify it, but it's worth briefly going over how the project and the foundation are entirely separate entities, because I'm certain that there will be people who aren't aware of that when going over this RFC.

For example, I believe that this isn't the case for the Python Software Foundation and the Python project, which are two parts of the same whole, although I could equally be misled about that.

[rust-rfcbot]

Team member @Kobzol has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Kobzol
• @ehuss
• @joshtriplett
• @lqd
• @m-ou-se
• @oli-obk
• @traviscross

Concerns:

• funding-team-non-self-perpetuating resolved by Propose the Rust Foundation Maintainer fund #3931 (comment)
• funding-team-terms resolved by Propose the Rust Foundation Maintainer fund #3931 (comment)
• leave-door-open-for-direct-appointment-by-teams resolved by Propose the Rust Foundation Maintainer fund #3931 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

Filing two concerns for the sake of capturing things in the RFC. I expect to file suggestions adding text for these, which I expect to be about one bullet point each, and then resolve them the moment that text is added.

@rfcbot concern funding-team-non-self-perpetuating

Briefly capturing a concern reasonably raised in the Council discussion of this:

We should record, in this RFC's description of the Funding team, that it is not desirable for this team to be self-perpetuating and self-selecting (e.g. a team that exclusively determines its own membership), and that it would be appropriate to handle it some other way that the various project teams feel connected to, such as appointment by the Council (or in the future a parent team of the funding team if any). This is particularly important because this team will be handling and directing funds.

@rfcbot concern funding-team-terms

Capturing a second such concern: we should have time-based terms for members of the Funding team. Members could serve multiple terms, but among other reasons, having terms gives people a natural and stigma-free way to rotate out.

[nikomatsakis]

@joshtriplett suggestions merged.

[traviscross]

Thanks @nikomatsakis for pushing this forward. And thanks to everyone on the RFMF subcommittee for their work leading up to this.

@rfcbot reviewed

[traviscross]

@rfcbot concern leave-door-open-for-direct-appointment-by-teams

(As described in #3931 (comment).)

[nikomatsakis]

Merged. I think the important part is that the team has terms, I think that the means of selection can be adjusted as we go easily enough.

[traviscross]

Thanks. Agreed.

@rfcbot resolve leave-door-open-for-direct-appointment-by-teams

[joshtriplett]

@rfcbot resolve funding-team-non-self-perpetuating
@rfcbot resolve funding-team-terms
@rfcbot reviewed

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[traviscross]

View changes since the review

Suggested change

	Selecting Maintainers in Residence is a collaboration between the Foundation and a "Funding team" appointed by the Leadership Council. This Funding team will weigh the set of applications against the project's needs and priorities.
	Selecting Maintainers in Residence is a collaboration between the Foundation and a "Funding team" whose members are appointed by the Leadership Council or selected directly by the top-level teams. This Funding team will weigh the set of applications against the project's needs and priorities.

For consistency.

[joshtriplett]

Suggested change

	Funding team members must not disproportionately come from any one company, legal entity, or closely related set of legal entities, to avoid impropriety or the appearance of impropriety. If the Funding team has 5 or fewer representatives, no more than 1 representative may have any given affiliation; if the Funding has 6 or more representatives, no more than 2 representatives may have any given affiliation. (This affiliation limit comes from [RFC 3392](https://rust-lang.github.io/rfcs/3392-leadership-council.html#limits-on-representatives-from-a-single-companyentity), and the Funding team charter should import the definition of affiliations and the processes around handling them should be imported from there.)

View changes since the review

[m-ou-se]

Yeah, it seems very reasonable to have affiliaiton limits for this team. Good catch. I'm not sure if we should define the exact rules in this RFC, or just say that there should be limits and leave the details for later.

[tmandry]

I would prefer not to spell them out in the RFC. My experience has been that these limits have been overly restrictive in the past.

To make this more concrete: Let's say the funding team consists of 5 members, and 2 of the nominees work in different parts of the same large company. What is the kind of impropriety we are trying to prevent in this situation? (As sometimes happens, we may struggle to get even 5 nominees that we feel are qualified, despite our efforts to recruit.)

[teor2345]

Based on my experience of grants teams in other communities, the most frequent concern is (potentially) biased decision-making. For example, a sub-group (appears to) select a maintainer that favours their goals, rather than using established goal-setting processes.

There doesn't have to be any actual bias. I've seen preventing, investigating, and addressing concerns take up a huge amount of volunteer time and attention. I've been on committees like that, and it's very draining.

The thresholds can be adjusted. But the overall aim is to look diverse and independent to a casual observer.

Separately, just a minor wording tweak to the last sentence in Josh's suggestion:

Suggested change

	Funding team members must not disproportionately come from any one company, legal entity, or closely related set of legal entities, to avoid impropriety or the appearance of impropriety. If the Funding team has 5 or fewer representatives, no more than 1 representative may have any given affiliation; if the Funding has 6 or more representatives, no more than 2 representatives may have any given affiliation. (This affiliation limit comes from [RFC 3392](https://rust-lang.github.io/rfcs/3392-leadership-council.html#limits-on-representatives-from-a-single-companyentity), and the Funding team charter should import the definition of affiliations and the processes around handling them from there.)

[joshtriplett]

https://github.com/rust-lang/rfcs/pull/3931/changes#r3087890684

View changes since this review