1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
Title: Rust, or: how to run a community
Category: Blog
Date: 2020-04-08
Tags: free software, culture, politics
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?
[e-mail collaboration]: https://spacekookie.de/blog/collaborating-with-git-send-email/
|
