diff options
author | Katharina Fey <kookie@spacekookie.de> | 2020-04-08 17:50:19 +0200 |
---|---|---|
committer | Katharina Fey <kookie@spacekookie.de> | 2020-04-08 18:46:36 +0200 |
commit | f34e5b2cbe7f496b5492efcee659af8b2a1832b3 (patch) | |
tree | fe75165118f09e5ea6380ecfa6db618934121fe2 | |
parent | c92a16b4f4e7c08334958e0c54ae2084cf7d9a9f (diff) |
Adding first draft of "how to run your community"
-rw-r--r-- | content/blog/116_how_to_run_your_community.md | 50 |
1 files changed, 50 insertions, 0 deletions
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? |