From f34e5b2cbe7f496b5492efcee659af8b2a1832b3 Mon Sep 17 00:00:00 2001 From: Katharina Fey Date: Wed, 8 Apr 2020 17:50:19 +0200 Subject: Adding first draft of "how to run your community" --- content/blog/116_how_to_run_your_community.md | 50 +++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 content/blog/116_how_to_run_your_community.md (limited to 'content') diff --git a/content/blog/116_how_to_run_your_community.md b/content/blog/116_how_to_run_your_community.md new file mode 100644 index 0000000..32130e6 --- /dev/null +++ b/content/blog/116_how_to_run_your_community.md @@ -0,0 +1,50 @@ +Title: Rust, or: how to run a community +Category: Blog +Date: 2020-04-09 +Tags: free software, culture, politics +Status: Draft + +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. And there's large 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? -- cgit v1.2.3