Translator: Guo Xiaoshuang/Post editor: Zhang Handong
Original text: blog. M – ou se/rust – is – not…
This article is written by Mara(Rust Library Team Leader) about the open source governance of Rust projects.
Not the company
In most companies, directors and shareholders and so on are at the top of the hierarchy and they set the goals for the company. Goals, milestones, deadlines, and things that are expected to move the company toward its ultimate goals; Usually it’s money.
Then there are several layers of management across departments and teams to divide the workload. Everyone is responsible for part of the goal, making sure their part is met, and ultimately assigning tasks to employees at the bottom of the hierarchy, all working toward the main goal in some way.
While the structure behind large open source projects like Rust looks similar from a distance, it’s usually upside down. In such a project, the goals and objectives are not the top team’s, but the contributors’.
For example, as a library team, we could try to decide that we should rewrite the formatting mechanism (STD :: FMT) to make it smaller and more efficient. But making the decision doesn’t make it happen. And we have no staff to assign tasks. That’s not how it works.
Instead, a contributor with a passion for formatting algorithms may come along and start researching these things. Our job as a library team is to empower this person. Make sure their plans are aligned with the rest of the library, review their changes and provide useful constructive feedback, set up a working group to help them organize everything if more people show up to work on this, etc.
Companies don’t let new people just randomly show up to do something. Done well, this is what makes open source special and so wonderful.
Personal goals
Ideally, the project goals of an open source project like Rust are simply a combination of the personal goals of everyone involved. It’s tricky. Because when a new person comes along, we don’t assign them tasks that fit our goals. Instead, the person has his own goals and ideas, adding to an already very diverse pool of potential conflict goals.
That’s why an open source project run by volunteers needs a management structure. You can’t have a hundred people with their own goals and hope for the best.
So what management does is take all the personal goals from everyone working on a topic and try to guide them in a way that makes things work. This may involve saying no to ideas that don’t fit into other ideas, or it may take a lot of discussion to fine-tune the idea to make it fit. This is the exact opposite of how a typical company works, where the goals come from the top, where management decides how to break it up and assign it to the people who do the technical work.
While many open source projects, including Rust, do have an overall direction or roadmap, these must be based on the goals of individual contributors to be successful. Saying “our main goal for 2021 is to improve the formatting mechanism in the standard library” will empower those who are already working on it, and attract those who already want to do something similar. This will help them because we will now prioritize any management decisions and code reviews they need. It allows people to focus and get more done. But without those contributors, setting such a goal is meaningless. Unlike companies, we don’t choose what people do with their time, and we don’t hire people to assign tasks.
This is a very good thing.
That’s why people want to work on Rust.
I’m not saying you can’t manage programming languages “from the top down” like a company. Many programming languages have been and are being developed very effectively in this way. However, I will say that I personally do not want the Rust project to work this way.
I don’t want to run rust’s warehouse department. I want to empower people who want to improve the Rust language library.
Vigorous space
Different contributors have different goals, work in very different ways, and need something completely different from the management structure.
For some of them, we have processes in place to make their jobs easier. People who want to develop new language features can submit their ideas in the form of an RFC and join discussions with the library team for advice and guidance. People who want to improve some important part of the compiler implementation can submit an MCP (majorchangeproval) and discuss it with the compiler team. If someone wants to fix a bug in the standard library, they can submit a PR and have it reviewed by someone who knows the context.
In other words, we provide a lot of space for contributors. The space to work, the space to ask questions, the space to get help, the space to earn recognition, every space that helps them get things done.
However, we didn’t create the right space for some types of hapless contributors.
Ideally, the Rust team’s work until recently has been focused on API design. The compiler team only focuses on the development of critical issues. Minor changes are reviewed by a single library reviewer. But there is no management of change in the larger domain. This means that there is no suitable space for people who want to overhaul and change STD: : FMT implementations. Without a team to work with or participate in, this goal is more difficult, or even impossible, for people who want to change STD: : FMT implementations.
That’s why I formed the new library team.
Making room for one thing often (accidentally) results in space being taken away from something else. If a man doesn’t understand things, but they want the practice of the application of the standard library design experience, and very much concerned about the interface of the standard library, but zhou will mainly discuss how to make less bugs above, before the next version of how to solve the problem of existing things, then he is not in one week will be very positive on it.
We now have library contributors. This is a space for managing people who are more involved in the project than the average person, but are not involved in the decisions of the overall team. For example, we have space for people who only work on specific parts of the library, or help with reviews. A year ago there would have been no room for one person to review the library implementation without a better team.
With the authorization and help of the core team and library team members, I was able to make these team structure changes. In turn, these changes are expected to enable the members of these new teams to thrive, which in turn will benefit more contributors and ultimately all users of the language.
Keep the change
I don’t think we’ve succeeded in creating space for every possible contributor yet. But once the dust settles on the restructuring of the team, I do think the results will be an improvement over where we were and more in line with the current project.
The “here and now” becomes an important part of this. These teams are designed around current members and people I see as potential members in the near future. But the needs of team members can change, sometimes surprisingly quickly. In a project that is defined entirely by the people who contribute to it, it can change quickly when things change about the project and its structure.
In 2018, the Library team was heavily involved in mentoring the author of popular Crate. The team released a set of guidelines that will review Crate and work with crate’s authors to implement it. All of this is done to improve the consistency and quality of the Rust Crate ecosystem.
Up until a few days ago, this was technically part of our team’s stated goal, even though it doesn’t happen much anymore; Especially since Ashley Mannix was gone for a while. If no one makes it their personal goal, it won’t happen.
This is a very good thing.
There are a lot of things on everyone’s Rust bucket list that aren’t happening because no one is doing it. We are not a company with deadlines and milestones that we need to meet. We are a diverse and rapidly changing group of people who are passionate about making the things we want to work on happen. Including a group of people who are passionate about managing all of this, trying to make room for all of this effort to happen.
There are a lot of things that we should have room for, but there isn’t room for right now. But if we keep working hard, we keep making small improvements. Continue to adapt. Continue to focus on the people around us who want to make a difference as well; Empower them and each other. Then each step will be a step in the right direction, enabling Rust and all those who have contributed to it to thrive with it.