Santiago Pastorino: Maintainer Retention

I’ve decided to start a series of listening sessions on rust governance to help build awareness and a shared understanding of our problems and ideas for fixing them. This post represents the first in a series of interviews I plan to give. I plan to record them, though I leave that to the discretion of my interviewees.

Let’s begin with some formal introductions. My name is Jane Losare-Lusby. I am a California-based principal software engineer employed by Futurewei Technologies to contribute to the Rust project full-time. I joined the Rust project in late 2019, first working on Clippy before moving on to error handling and the libs team, and most recently contributing to the development of the rust-lang governance RFC as a member of the governance working group. I’m currently an active member of the Style Team and one of five project directors representing the Rust Project on the board of directors of the Rust Foundation, with my specific focus being the area of collaboration¹. Uruguayan software engineer Santiago Pastorino is today’s interviewee. He joined the Rust project around 2017 and is today a compiler team contributor, co-leader of the rustc-dev-guide working group, co-founder of WyeWorks, and RustLatam conference organizer. Futurewei also provides funding for Santiago to maintain the Rust compiler.

I just finished conversing with Santiago Pastorino on Rust governance, what changes we need to make the project healthier, what should be the top priority for the council’s backlog, and other thoughts on Santiago’s mind. First and foremost, we talked about Santiago’s views on the council’s most pressing problem, which needs immediate attention. According to Santiago, retaining project participants instead of alienating or driving away our most valuable resource—our people—is the most pressing issue we must address. We’re failing in this area in various ways, so we must approach this from multiple perspectives.

The first aspect we discussed was accountability in leadership, what it should look like, and how to apply it consistently. Santiago emphasized the importance of making room for people to make mistakes and grow in leadership positions and the need for consequences when people are not learning from their mistakes but as the very last option that we would do our best to avoid. Not being clear about when consequences become more severe can have a chilling effect on people participating in leadership when it creates this feeling that you aren’t allowed to make mistakes, which doesn’t feel realistic; nobody is perfect. We need to create a supportive environment where so long as people are learning and accountable that they feel safe and like they have the opportunity to grow into their roles. We discussed the meaning of accountability vs. responsibility and how accountability means being answerable to others. It’s about transparency when project members in positions of trust make mistakes, so people can make sure we’re learning the proper lessons from them and treating those mistakes with the appropriate gravity they deserve. We talked about the importance of safeguards and having well-defined processes so that there is clarity and less opportunity for people to make mistakes in ways that cause harm.

We also talked briefly about other contributing factors, such as burnout and conflict, though we did not dig into these in detail. We generally acknowledged that many contributing factors need to be accounted for and worked on separately to improve retention.

We discussed how, when it came to accountability, for good or bad, we weren’t consistent in that some of the people involved came forward, but not all of them. Therefore, it is evident that members of project leadership made individual decisions based on each person’s feelings rather than discussing accountability as a group and applying it consistently. We discussed his personal experience of when he witnessed leadership follow a similar pattern, rejecting a particular initiative because they wanted to carry out the task themselves in a larger and more official capacity. He discussed how this was disempowering for the contributors who were eager to lead the initiative. Their objections were based more on personal preference than constructive criticism of the proposal’s shortcomings. The cost of ending these initiatives goes beyond the work that is lost; it also includes the emotional toll it takes on the contributors who are told no, how it alienates them, how it makes them feel untrustworthy and unqualified to lead such a significant initiative, and how it adds to that feeling of alienation that causes maintainers to burn out and leave the project, which feeds back into the more substantial issue.

Next, we discussed difficulties around how people get into leadership positions in the first place and the need for clarity on how to end up in such a role. He noted how, in the Rust project, we have a culture of respect based on technical skills. We prefer to elevate those with the most technical skills to leadership positions, but this doesn’t make much sense since technical skills and leadership skills have little overlap. We discussed strategies and challenges in filling these roles and how, when an organization is less well structured and established, it’s important to promote people from within who are already familiar with the culture and needs of the project so they have a chance of being able to be effective. Long term, however, there are scaling issues here, and it’s essential to get to the point where you can onboard people who don’t have prior experience or connections and still have them be effective. Santiago feels it is necessary to have clearly defined roles and processes for people coming in from the outside to successfully navigate and contribute to an organization.

We also discussed how challenging it can be for an open-source project to attract people to fill these roles and the need for creative solutions to bring people in from backgrounds other than software engineering. I suggested paying people as a good starting point, and Santiago agreed. However, he noted how this introduces the risk of companies funding people to work on Rust, exercising undue influence over the project, and only accounting for their needs. The idea is that if the people hired are only there because it’s their day job, they may end up rubber stamping things, and if there are too many of them in one team, it might cause proposals to go through that don’t correctly account for the needs of all of our users. He emphasized that it’s still best to pay people, but we need to acknowledge and account for this problem explicitly, and he wasn’t sure of the best way to deal with it. I suggested that we have a few tools in place already that we can use to resolve this, a combination of affiliation limits for teams, the consent decision-making process and its focus on objections, and open processes to maintain an awareness of users’ needs. The idea here is that even if you have a majority of people on a team just essentially rubberstamping because of pressure from their employer, all you need is one person listening to the needs of the users and escalating their needs as objections to the proposal, so long as everyone holds each other to the established process. Even then, this scenario isn’t super likely so long as we have affiliation limits since you’d never have a majority of people on any team from one organization. I also emphasized how it’s important to remember this risk in the context of these policies so we don’t forget their motivations and introduce processes like majority voting or overruling objections, which make it easier to ignore minority needs and exacerbate the risk of undue influence.

Next, we discussed the keynote selection process and how it ties into the bigger retention problem. Santiago lacks clarity on why leadership needs a say in the keynote since we already have a program committee of project and community members that effectively represent the project and select all other talks. He is open to the possibility that there are valid reasons he doesn’t know, which he would agree with. Still, he worries that this is just another case of leadership not empowering others to make decisions and communicating a feeling of distrust that further alienates people within and around the project.

Finally, the last thing we discussed on this topic was the communication between leadership and the rest of the teams. How our team members were learning about the keynote fiasco and the context simultaneously as the rest of the community, and how that can contribute to feelings of alienation and being unvalued. He asked, “Is it okay that teams only learn about these problems when the rest of the internet does?” and generally expressed the sentiment that he thinks the answer is no; it’s not okay. He was unsure where to draw the line, who to keep informed and who not to, and how time pressures can play a role. He suggested that not keeping our project members informed contributed to the confusion since many were left to run to social media with their conjecture, creating more chaos and that if we had told them, they could have helped calm the situation while leadership focused on public statements of accountability. He suggested a potential method of propagating this information through the leads and representatives that link teams to the council and how, in the future, next time something like this happens, it should be the responsibility of those inter-team links to call emergency meetings to keep their members informed and answer questions, and how this would contribute to a sense of connection within teams and of being valued.

In our discussion, Santiago shared his belief that maintainer retention is the biggest issue the council should focus on. That the problems with retention stem from insufficient, inconsistent, and unclear accountability in leadership, a lack of trust in project members from leadership, filling leadership roles based on technical skill rather than leadership skill, and a lack of clarity about how to get involved and contribute to the project in a leadership capacity.

These initial interviews focus on problems because the first step in solving these problems is building consensus on what they are. Solving these generally acknowledged problems can then serve as the shared goals that unite and direct our collaboration, making it easier to work together and avoid misunderstandings than if we jumped straight into proposing solutions, leaving others to guess at our motivations. My hope is that the most effective way to work towards solving these problems is to rebuild trust starting with a foundation of shared goals and shared understanding and that these interviews and the shared goals they establish will be an effective strategy for us to invest in trust and connection with each other.

https://foundation.rust-lang.org/about/ ↩