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.

[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 from there. The Leadership Council may update this policy through its normal decision-making process.)

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]

@teor2345 Thanks for the typo fix; incorporated into my original suggestion.

@tmandry wrote:

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.

Based on your second sentence, I very much think they do need to be spelled out in the RFC. I don't think we should relitigate these, and I grabbed the ones from the Council precisely because they're terms we're already familiar with.

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?

I'll second everything @teor2345 said. The impropriety, or appearance of impropriety, is precisely that the funding team is in the position of prioritizing the allocation of funds within the project and selecting/nominating candidates within the project, and could very easily prioritize those known to a particular company or those whose goals align with a company. This does not even have to be intentional, but simply a matter of familiarity. A set of team members with diverse affiliations avoids either doing that or raising the question of it.

[teor2345]

Thinking about this some more, here's one scenario I expect will come up:

• a company donates to the fund
• staff of that company are on the funding team, which decides how to spend that donation
• someone is concerned about staff spending company donations (either inside the company or inside the Rust project)

Currently, the proposed mitigations are:

• most sponsors pool their funds (but this is not guaranteed)
• affiliation limits

Is there an existing conflict of interest policy that applies, or could be imported (perhaps with modifications?
Should affiliates also recuse themselves from decisions to spend un-pooled donations from their company?

(Recusing from pooled funds is impractical because tainting is long-term, and hard to remember. Some kind of "majority of this year's donations" check might be possible, but it's still complicated. Recusing from discussions is also tricky, because a lot of discussions happen async.)

[tmandry]

Based on your second sentence, I very much think they do need to be spelled out in the RFC. I don't think we should relitigate these, and I grabbed the ones from the Council precisely because they're terms we're already familiar with.

You're saying that because I've seen them be overly restrictive, you want to keep them as-is and spell them out in the RFC. It's.. hard for me not to see that as a low-trust way of engaging with my perspective.

I should be explicit that I am saying this with my project member hat on, but also with the perspective of someone who works for a large company. To clarify something that you might be reading between the lines of my comment, these limits have not been overly restrictive to any company I've ever worked for. In fact, I have never heard a company complain about representation limits. In my view, they have been overly restrictive to the project.

The instances that inform my thinking involve large companies (not one I work for), where two excellent project members happen to work for the same company on completely different teams, and are unlikely to collude. The policy is restrictive because it leaves no room for project leadership to evaluate risk and make a judgment call.

In short, I think treating every entity, no matter the size, as equal is overly simplistic and restrictive. We should absolutely have a policy here that prevents impropriety or the appearance of impropriety – and we should look for ways to improve the policy and guidance over time.

Another way it can be overly restrictive is that the project may later decide it wants the perspective of sponsors explicitly represented on the funding team. This is not the way I would set it up initially, because I'm not sure it's necessary or a good idea. But we discussed this possibility many times on the committee, so I would be surprised to preclude it directly in the RFC. I'm saying this part mostly with my project hat on – but also with my "internal company Rust sponsor" hat on – because I want to give the Council options that make funding more appealing.

Concretely I propose setting an initial policy, but giving the Council latitude to update that policy over time. That can be accomplished by adding a sentence like:

The Leadership Council may update this policy through its normal decision-making process.

[joshtriplett]

You're saying that because I've seen them be overly restrictive, you want to keep them as-is and spell them out in the RFC. It's.. hard for me not to see that as a low-trust way of engaging with my perspective.

That was not at all my intention here, and my apologies for coming across that way.

My reaction was entirely one of remembering the extensive discussions on this exact point during the design of the Council, and not wanting to replay those same arguments in substantially similar form. That doesn't preclude having the conversation. My goal in spelling out the initial policy in the RFC was specifically to have something to start with that we have precedent for and have operated with for a while now, in order to make forward progress.

To clarify something that you might be reading between the lines of my comment, these limits have not been overly restrictive to any company I've ever worked for.

I was not reading anything between the lines there; again, sorry for the implication.

The instances that inform my thinking involve large companies (not one I work for), where two excellent project members happen to work for the same company on completely different teams, and are unlikely to collude. The policy is restrictive because it leaves no room for project leadership to evaluate risk and make a judgment call.

Part of the point is that bad things can happen even when people aren't colluding or otherwise acting in bad faith, because working for the same company and modeling their thinking and priorities day in and day out will tend to affect your thinking, not necessarily intentionally. So, several people working for the same company can end up bringing similar mindsets or priorities to bear without ever having coordinated with each other.

I think when people see affiliation limits and conflict of interest policies like this, the natural inclination is to assume that they're guards against malice; however, I would expect the vast majority of the time they avert unintentional problems.

Another way it can be overly restrictive is that the project may later decide it wants the perspective of sponsors explicitly represented on the funding team.

I would be surprised to preclude it directly in the RFC.

I would not expect this language to preclude that in any way; my expectation would be that if we have some process to, for instance, add a representative of sponsors above a given threshold, that wouldn't run afoul of this limit. We could even, at that time, decide to state that the official sponsor representatives didn't count towards the limit, if we thought that would be an issue. (I wouldn't expect it to be, though, in practice.)

Concretely I propose setting an initial policy, but giving the Council latitude to update that policy over time. That can be accomplished by adding a sentence like:

The Leadership Council may update this policy through its normal decision-making process.

I would already have assumed it to be the case that the Council could update the policy (and anything else about this), but I've added that sentence to this suggestion, to make that explicitly clear. That seems like a good idea.

[joshtriplett]

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

View changes since this review

[joshtriplett]

@rfcbot concern affiliation-limits