A governance system, if you can keep it

One of the most famous anecdotes that forms the basis of the United States’ political self-identity is the story of an interaction between Benjamin Franklin and Elizabeth Willing Powel after the Constitutional Convention of 1787, which established the United States’ present form of government. Powel asked Franklin what sort of government the U.S. was to have, to which he replied: “a republic, if you can keep it.”

Given the self-conscious references to “constitutions” and “checks and balances” in the Rust project’s recent governance RFC and the discourse around it, some further reflection on this quote and its implications about governance as such might now be appropriate for the project and its community.

Last week, I wrote on Twitter that sometimes the problem is governance, but usually the problem is power. What I meant with this remark was that organizational problems that appear as inadequacies in the formal system of governance are most commonly just the manifestations of an underlying problem that has arisen from the informal exercise of power by members of that organization, outside of (if not in direct contradiction to) the formal rules of governance of the organization.

This is also one of the key lessons of Franklin’s quote: a system of governance is only as good as the behavior of those who are governed by it, especially their commitment to follow its strictures. This behavior is not controlled by the governance system, but by the norms of those who implement it. If they choose to act outside the formal processes of governance, and not to hold one another accountable when they do, the governance system itself cannot do anything about it. It is a document describing a procedure, after all, which is not agentive.

I don’t have a particularly strong opinion on the specifics of how the Rust project should be governed, except that it should be governed by some - really, any - formal mechanism. This seems to be the consensus across the board in the RFC discussion as well; some prominent contributors express concern over how the RFC was drafted, for example, but indicate support for adopting it because the current situation is untenable. However, I have been somewhat dismayed (if, frankly, unsurprised) to see a blind spot in the present discussion around exactly how the Rust project came to lack meaningful a formal governance system, and what would need to change to prevent that process from reoccurring.

For indeed this is not the first Rust governance RFC. The previous governance RFC was accepted in 2015, and is (with the current RFC still not accepted) officially, formally, the description of how the project is governed. But reality has shifted over time, and by about 2021 that RFC’s description of how the project is governed bore basically no similarity to how things worked in practice. The core team still existed, but some important teams had no representation on it, and it no longer functioned to coordinate the project. Questions that seem relevant to the Rust project now, but which have at least publicly been little explored, are how the practice of the previous governance RFC came to an end, how the new RFC is substantially different from the old, and how a similar slippage will be prevented in the future. Otherwise, what is the point of all this time so many have put into this new governance RFC?

In many respects, the new RFC mirrors the old RFC. The core team was supposed to function as a “council” representing all of the subteams, which were to be delegated the majority of the important decisions. And decisions were to be made by consensus, with a preference for the public and formal RFC process. The difference between the new council and the old core team is chiefly that council membership is intended to rotate annually, with a suggested “term limit” of 3 years (though this is explicitly not a hard requirement, and a team can decide not to change its representative). Also, there are restrictions on the number of members that can be employed by the same company (which would have been an absurd requirement in 2015).

On the other hand, the relationship between the council and the moderation team has been much more formally described than in the previous RFC. It was the intent in the previous RFC as well that the core team would be bound by the decisions of the moderation team (Aaron Turon spoke several times to me with pride about the “separation of powers” implemented by having no representative of the core team on the moderation team). But how the moderation team was to function was largely left unexpressed. The introduction of “contingent moderators” and a system of audits is clearly intended to create productive avenues for disagreement between the moderators and other teams. That this is a response to the events involving the moderation team in 2021 is obvious.

A lot of attention is given in the new governance RFC to mechanisms with the evident intent of limiting the role of the council as a nexus of power in the project, ensuring its subserviance to the teams which it is intended to coordinate. But maybe the real problem that led to the collapse of the old system was not the explicit manifestations of power in the formal leadership body, but the informal and hidden power held by key stakeholders, who use that power through backchannels outside of the official system to make it effectively redundant, who have a clear “in group” and “out group,” who have avoidant conflict styles and take disagreement as a personal attack, who develop an internal culture of privately disrespecting those outside of their group and dismissing their contributions. Maybe. If that’s the case, what in this RFC would stop that behavior from continuing to erode the system of governance, until Rust lands exactly where it is again?

The RFC contains lengthy commentary on accountability, responsibility, transparency and the duty of project leadership to act in a manner appropriate to their role in this regard. This largely focuses on the responsibility of council members, but of course this responsibility belongs to all project leadership, regardless of their formal appointments. And more to the point, these comments are not ultimately enforceable, except by the leadership itself. Will the Rust project leadership do the necessary soul searching and personal growth to begin implementing new norms that could heal the project and set it off in a more positive direction? Will enough of them be firm enough with those who fail to uphold these norms that they become so embedded in the culture that they can be taken as a given?

Or will they continue their old ways? Delegating the work they don’t enjoy without delegating the power they do enjoy? Maybe this apathy toward “non-technical” work will result in the announcements of ill-thought out policies on aspects of the project no one likes to think about (say, the official trademarks). Maybe this refusal to delegate real power will result in retracting a keynote offer after the fact when a real decision maker decides they don’t like that talk after all. Maybe, maybe, maybe…