Adding first draft of "how to run your community"

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?