Rust, or: how to run a community

⇠ back | date: 2020-04-08 | tags: culture, free software, politics | duration: 02:19 minutes

This will very much be an off the cuff post about community building with insights that I've seen from various communities I was a part of in the last 10 years. None of this is to be taken as facts, and is entirely personal opinion. I do hope however that this post might make one or the other think about how we run communities. Really… I'm just bored and want to write something.

The communities I've been a part of involve Rust, Fedora, Moonscript (a lua coffee script type), libgdx (a Java game framework), Nix(OS), and the Homeworld 2 modding community that's to blame for me learning to code and unleashing my terrible puns on the world.

There seem to be two avenues of community organising: centralisation and distribution. One favours building a community around a shared name, domain, communication channel, and workflow. People work on the same things, in the same place, under the same name. This can work really well for smaller projects, and generally means less friction when people from different backgrounds have to talk to each other, because everybody is kinda in the same place. This is how most communities get started, and how Rust was working until about one year ago.

There is a fundamental problem with this model though: at some point your community will become too big, and people will start to fracture out into their little bubbles. There's no fixed point at which this happens, but it seems to happen sooner or later for most projects.

I think as community builders it is our job to embrace these fractures, letting sub teams spin off into their own little ventures, while using the shared name to advertise these ventures. I think it's okay to not have a project represent as a closed front to outsiders, but very much embracing the fact that projects are run by many individuals that chose to collaborate on something larger than themselves.

The reason why I'm such a big fan of e-mail collaboration via mailing lists (both for conversations and sending patches) is that it encourages this separation. A project that forces people who cross-collaborate to jump from tool to tool is just as centralised as a project that only has a single communication channel. But there's definitely examples of projects that have grown into little bubbles that still work on a shared "product", without having to all do it in the same place: the Linux kernel.

Whether you agree or disagree with my take on e-mails, I think we should all be aware of the finite size that a community can have. And at what point should we start to embrace community mitosis?