Last year, as an occasional contributor to the Rust project, I did not think much about the organisational structure of the team behind the project. I saw a hierarchy of teams and groups, team leaders, etc. Just like any other organisation. This year, after getting more involved, becoming a library team member and eventually team lead, I spent some more time thinking about why we have this structure, what these teams are for.

Not a company

In most companies, there are directors and shareholders and whatnot at the top of the hierarchy, who set goals for the company. Targets, milestones, deadlines, things that will hopefully drive the company towards whatever the ultimate goal is; usually money.

Then there are several layers of management split over departments and teams to divide up the workload. Each taking care of part of the targets, making sure that their part gets done, eventually assigning tasks to the employees at the bottom of the hierarchy, all working towards the main goal in some way or another.

While the structure behind a big open source project like Rust can look similar from a distance, it’s often completely inverted. In such a project, the targets and goals are not those of the top level team(s), but effectively those of the contributors.

For example, as the library team we could try to decide that the format machinery (std::fmt) should be rewritten to be smaller and more efficient. But making that decision doesn’t make it happen. And we don’t have employees we assign things to. That’s not how this works.

Instead, a contributor with a passion for formatting algorithms might show up, and starts working on these things. Our job as the library team is to empower this person. Make sure their plan is in line with the rest of the standard library, review their changes and provide useful constructive feedback, if more people show up to work on this, set up a working group to help them organize it all, etc. etc.

Companies don’t get new people randomly showing up to work on something. That’s what makes open source special and such a wonderful place, if done right.

Personal goals

Ideally, the project goals of an open source project like Rust are simply the combination of personal goals of everyone working on it. And this is tricky. Because when a new person shows up, we don’t assign them a task that fits with our goals. Instead, this person comes with their own goals and ideas, adding to an already quite diverse set of potentially conflicting goals.

And this is why an open source project run by volunteers needs a management structure. You can’t just put together a hundred people with each their own goals, and hope it all works out.

So what the management does, is take all the personal goals from everyone working on a certain topic, and try to guide them in a way that things will work out. That might involve saying no to ideas when they would not fit with other ideas, or it might involve lots of discussion to align ideas to make them fit. This is exactly opposite of how it works in a typical company, where the goals come from above, and the management decides how to split it up and assign it to the people doing the technical work.

While many open source projects, including Rust, do have an overal direction or roadmap, these have to be based on the goals of the individual contributors in order to succeed. Saying “our main goal in 2021 is to improve the formatting machinery in the standard library” would empower those already working on it, and attract those that already wanted to work on something like that. It would help them because we’d now prioritize any management decisions and code reviews they need. It’d allow people to focus, and get more done. But without those contributors, setting such a goal is meaningless. Unlike a company, we don’t get to choose what people spend their time on, and we don’t hire people to assign tasks to.

And this is a good thing.

It’s the reason why people want to work on Rust.

I’m not saying a programming language couldn’t be managed ‘from the top’ like a company would. Many programming languages have been and are being developed that way very effectively. What I am saying, however, is that I personally don’t want the Rust project to work that way.

I do not want to manage the library department of the Rust company. I want to empower the people who want to improve the libraries of the Rust language.

Space to thrive

Different contributors have wildly different goals, work in very different ways, and need completely different things from the management structure.

For some of them, we have processes in place to make their job easier. Someone who wants to work on a new language feature can submit their ideas as an RFC and join a discussion with the library team for advice and guidance. Someone who wants to improve some big part of the compiler implementation can submit a MCP (major change proposal) and discuss it with the compiler team. And someone who wants to fix a bug in the standard library, can submit a PR and get it reviewed by someone who knows the context.

In other words, we have made space for these kind of contributors. Space to do their work, space to get feedback, space to get help, space to get recognition, whatever space they need to succeed.

However, there are unfortunately many kinds of contributors for which we have not made space, or not the right space.

Until recently, the library team was mostly focussed on API design. Critical implementation issues were handled by the compiler team out of necessity. Smaller implementation changes were reviewed by individual library reviewers. But there was no management of larger implementation changes. This meant that there was no space for someone who would’ve wanted to overhaul the std::fmt implementation. There was no team they could go to or be part of to work on this, making it a lot harder, or outright impossible, to achieve their goals.

This is why I started the new Library Team.

Making space for something can often lead to (accidentally) taking away space from something else. Someone who is not involved much in the implementation of things, but wants to apply their experience in API design and cares deeply about the standard library’s interface, would not thrive in a team that likes to have weekly meetings talking about implementation soundness bugs and how to work around them before the next release.

This is why we now have the Library API Team.

We also now have the Library Contributors. A place for those who are more involved in the project than the occasional contributor, but who are not part of the teams making the overall decisions. This makes space for those who want to, for example, work on only a specific part of the library, or help out with reviewing proposed changes. Until about a year ago, there was no space for someone to review library changes or get more involved in other ways, without directly being part of a team with many more responsibilities.

I was able to make these team structure changes with help from the core team and the library team members, who empowered me to do this. In turn, these changes hopefully empower members of these new teams to thrive, and in their turn empower many more contributors, eventually benefiting all users of the language.

Keep changing

I don’t have the impression that we’ve now successfully created space for every possible contributor. But once the dust of the reorganisation settles, I do think the result will be an improvement over what we had before, and fits better with the project as it is right now.

“Right now” being the important part there. These teams are designed around the current members and the people who I think might become a member in the near future. But this group of people and their needs changes, sometimes surprisingly fast. And in a project that’s entirely defined by the people contributing to it, that changes the project itself and the structure that it needs, just as quickly.

In 2018, the Libraries Team was much involved in guiding authors of popular crates in the ecosystem. The team published a set of guidelines, and would review crates and work together with crate authors to implement them. All of this to improve consistency and the quality of the Rust crate ecosystem.

Until a few days ago, this was still technically part of our team’s explicit goals, even though not much of this was happening anymore; especially since Ashley Mannix left a while back. Without people who have it as their personal goal to make something happen, things just don’t happen.

And that is fine.

There’s many things on everyone’s Rust wish list that are just not happening because nobody is working on it. We’re not a company with deadlines and milestones we need to reach. We’re a diverse and quickly changing group of people passionately making the things happen that we want to put effort in. Including a bunch of people passionately trying to manage it all, trying to make space for all these efforts to happen in harmony.

There are many things for which we should have space, but currently don’t have space for. But if we keep trying. If we keep making small improvements. Keep adapting. Keep looking out for those around us who want to contribute too; how we can empower them, and each other. Then every step will be one in the right direction, making Rust and all of the many people who work on it, and with it, thrive.