# Rust Project Affiliation Limits

The Rust Project and Foundation has affiliation limits for the Leadership Council and the Board of Directors.
These limits set an upper bound on the number of people in each group associated with a single company.
As we understand it, the goal of these limits is to prevent a single entity from gaining too much influence over Rust---in an extreme case to prevent Rust from essentially being captured by a large corporation.
We have had the chance to test these rules twice now, once in forming the Leadership Council, and again in electing new Project Directors.
In both cases, we found that these limits severely constrained our choices for these positions which also made it hard to achieve other goals such as diverse representation.
Thus, we would like to evaluate these limits in light of the full set of Rust project goals and if needed propose changes to them.

## Goals

We would like an affiliation limit policy that achieves the following goals.
These are in priority order, so when two goals are in tension we should prefer the higher ranked goal.

1. Enable and support the long term health of the Rust Project.
2. Empower the Rust Project to independently pursue its goals free of undue influence from specific corporations and other entities.
3. Create leadership structures that reflect and grow the diversity of Rust contributors along many dimensions.
4. Protect the privacy of Rust contributors wishing to serve in leadership positions.

Rust is a language empowering everyone to build reliable and efficient software.
Our high level goal is to ensure the long term health of the Rust project so that it can keep pursuing this mission.
The other goals in this list are seen as supporting this high level goal.

At the moment, goals 2 and 3 are in their de facto order based on the current policies.
Our policies are strongly biased towards limiting corporate influence even at the expense of severely limiting the set of people who can serve in leadership positions.
This document is thus largely an exercise on whether the order of goals 2 and 3 should be reversed.

We place the goal about privacy after these because we want to preserve privacy as much as possible, while recognizing that serving as a leader is a trusted position and it is reasonable to ask leaders to disclose some additional information if necessary.
For example, we may ask them to share their employer, which is not otherwise expected of Rust project members.
On the other hand, this must be reasonable.
We should not require independent contractors to effectively disclose their entire customer list.
We also note that privacy is a matter of safety, as sharing some information can put project members at risk.

## Some Possible Alternatives

(TODO: How to evaluate the cost and benefit of each of these options?)

### Accept the Status Quo (i.e. Do Nothing)

Although we've had clear challenges from the affiliation limits, it may be that we decide they are still the best way we know to balance competing concerns.

For example, a few corporations employ or contract with a disproportionate share of Rust contributors.
While it makes it harder for people associated with those companies to serve in leadership roles, giving disproportionate representation to affiliates of those companies is arguably exactly what these policies are meant to prevent.

### Remove Affiliation Limits

We may decide that the affiliation limits do enough more harm than good that we should remove them entirely.

For the Leadership Council limits, we can do this on our own.
It would need an RFC since the current policy is established in the Leadership Council RFC, but doing so with completely within the scope of the Project.

For the Project Directors, making changes here require a change to the bylaws.
This is something we (the leadership council) would have to ask the Project Directors to bring to the attention of the Board and would be subject to a vote from the Board.
(Note that this applies to all other options that involve changing limits for Project Directors.)

### Raise Affiliation Limits

This is probably the smallest, simplest change we could make.
Increasing the limits even by just one would still place limit the potential influence from one entity but would likely make the constraints much easier to satisfy.

We might be able to do some simulations to see how much it changes the options for appointing people to each position, as well as how hard it would be for organizations to collude to capture the Rust project.

### Add Escape Hatches

Given that our experience that affiliation limits make other goals harder (particularly the goal of having diverse representation) by severely constraining the set of people we can appoint to these positions, we might be able to add an escape hatch when these conflicts happen.
A possible rule could be "if the only candidates representing X are conflicted out then those candidates are still eligible despite affiliation limits."

### Per-Cohort Limits

For both Project Directors and Council Representatives, we appoint them in staggered groups.
During the last Project Director elections, one large employer already had their maximum number of Board seats so anyone working for that company was immediately disqualified (which we realized rather late in the process, unfortunately).

We could say the limits now only apply per-cohort, but if we do this we might want to reduce them since the Council and Project Directors are both made up of two cohorts.

Another option is to set a minimum.
We could say for each cohort, at least one person from each company is always eligible for the position, but otherwise leave the existing limits in effect.

We'd also probably have to say this exception only applies for normal rotations and not cases where, for example, one member resigns and needs to be replaced.

### Clarify Rules for Contractors

We should do this regardless of the other options we take as it caused confusion during the Project Director elections.

There seems to be less ambiguity for the Leadership Council because the RFC uses the term "affiliation" rather than "employment."

For the Foundation, the bylaws say "employment," but the Foundation interprets this to cover those working as a contractor.
We believe this is within the Foundation's purview to decide how this term is defined in this context, so presumably changing would be something we'd need to ask the Project Directors to work towards.
But it might be something the Foundation staff could do on their own.

At a minimum, the Leadership Council should make sure our policy documents accurately reflect the Foundation's interpretation since that is the one we are bound by.

## Random Thoughts

- We want as many people as possible who want to serve in Rust leadership positions can do so.
- Contractors should not have to effectively disclose their client list to serve as a leader.
- Right now our practice considers someone who contracts for a single company to be employed by that company.
- If someone has many contracts then it seems unhelpful to have them say "1% of my income comes from X, 1.5% from Y, 7% from Z, 3.2% from W..."
- We don't want companies to use contractors as a way to skirt the spirit of the affiliation limits.
- Project leadership is a trusted role so requirements beyond those of project membership are acceptable as long as they have a strong justification.
- Serving as a Rust leader should not expose you to unnecessary risk.
- There are legal constraints on some of our options here.
- What do other projects do? Apparently affiliation limits are fairly standard stipulations in 501( c )(6) bylaws.
- We think of these limits as primarily protecting the Rust project from EvilCorp taking over the project, but it also gives organizations acting in good faith a defense from charges that they are trying to take over Rust, since they can point to their limited power.