Propose the Rust Foundation Maintainer fund

[nikomatsakis]

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]

OK, I've gone ahead and made edits. I marked conversations as resolved if I made edits in response to them or felt that no edits were needed. Please review the edits and raise comments for any remaining points!