Note: SaaSwrites is moving towards being open-source. If you think you have anything to contribute at any point in this article, feel free to do it. Here’s how you can contribute. SaaSwrites earns its commission through affiliate links encouraging other indie hackers to help purchase products made by indie hackers. If you happen to purchase any affiliate product, we make a small commission and our living :) Read our affiliate policy.
Updated on: 13/03/2022
Murtuza Bambotshares an Unpopular opinion: communities can grow indefinitely
He defies that community size has limits. It doesn't.
Most communities base their size on a study from Robert Dunbar.
Dunbar's number — the ideal size of a "tribe" — is 150. It's the max number of relationships a person can have. So they aim for 150 or 250 or 500 members. But Dunbar's number is irrelevant, and here's why
Members don't need deep relationships with EVERY other member.
Each member just needs 5 strong relationships, not 150.
With each member holding 5 strong relationships, retention is golden. So how do we need to model these fractional networks within the larger community? For this, we can look at... meerkats! Meerkats are awesome. They live in groups (called "mobs"), build a network of tunnels, & communicate using chirps. There's different chirps for predators & food — when a meerkat finds something, they alert others.
Meerkat mobs live in a balance. Too few & there's not enough to warn the others when a snake comes. They all get eaten. The min mob size is called "Allee's threshold" Too many & there's not enough food to support them. This is their "carrying capacity". Onto communities
Most of us recognize Allee's threshold in communities — you need 5-10 people to start & create what @rosiesherry calls a Minimum Viable Community.
Same idea with carrying capacity: too many community members & things get crazy & fall apart.
But there's a secret- Carrying capacity can be increased. Say there’s an extended spring & more fruit. The meerkat population will expand past its original carrying capacity. Likewise, great mods, sub-groups, events, & automation increase a community's carrying capacity.
Now your job changes
To build a large community, the process is simple:
1/ Create a Minimum Viable Community
2/ Scale up to carrying capacity
3/ Increase carrying capacity
4/ Scale up to new carrying capacity
Run this feedback loop over & over to scale to 1000s of members.
As digital-first communities grow, a common question emerges: “How should we nudge the member inflow / outflow?” This comes often in two flavors, presented by a community member:
How do we get more people to join?
Should we increase the price of membership? (More tokens)
What to ask ?
Instead of immediately making a change to membership criteria, I’ve found it useful to ask:
-> why are we asking this question?
-> is there a problem or opportunity with membership flows?
-> what part of our mission is supported by a change??
In many cases, adjusting the membership flow process can help the community and their mission. For example, by increasing the talent pool (eg new skills and energy!) or by limiting influx of new members (less energy on onboarding, more time to mature processes)
Building a community will have varying rhythms
Depending on how difficult it is to join (and participate / leave)
Ohm: membership requirements, as needed by community objectives
Volt: membership demand
Amp: New members
Case Study 1
FWB increased their price and created membership tiers. This supported a new operating model that supported growth of participation on the edges (newsletter readers, local chapters) while creating space for core contributors to build.
Case Study 2
The Nouns project created a core team and only allows one new member per day. This meant a slow and predictable stream of growth, creating strong space for participation and stimulating scarcity (higher price)
Case Study 3
Mirror has the weekly $WRITE Race, restricting the initial inflow (similar to nouns) but disconnecting participation from pure capital exchange (unlike Nouns or FWB)
In each case, we should expect membership to evolve over time - and changes to membership models should align with community ethics and mission.
For many communities that had an open or very accessible policy (eg join for 1 Cabin), it makes sense to consider decreasing influx once the community has hit critical mass for short-term and urgent priorities.
For example, decreasing member inflow is a good strategy if the core contributors are feeling overwhelmed or the community isn’t able to invest (healthily) in core operations. It’s important to maintain openness, as long as it’s balanced with the risk of burnout.
While considering membership, it’s useful to remember that constraints and flows don’t just exist at the initial gate - but then through onboarding…And through contribution zone paths.
In short: Build paths for the mission, balancing between community needs and individual member needs.