I’ve been thinking about Web-based community software for most of my life, now. Five years ago, I pondered what a “real” community was in the context of software and how badly we were failing at it. Since then, “community” has fallen out of favor among large corporations & tech monopolies as they continue to shutter existing platforms & tools and divest in community management & moderation. In that time, I refined my beliefs for what must come next.

I came up with five.

1. Communities should only be divided by individual choices: interest, labor, location, or belief (except beliefs that create additional divisions or restrict those individual choices).

This establishes both what a community should be about and what it should not be about. We should support the widest array of communities possible, but not those whose beliefs are fascist, racist, trans/homophobic, misogynist etc. This was the most succinct way I could find to summarize the problem with those beliefs: they create artificial divisions based on innate qualities and seek to restrict freedoms based on them. It is first in my list for good reason.

2. Sustainable communities must support diversity, equity, inclusion, & accessibility which requires an accountable power structure within the software and that the community owns its own data.

My second belief is about how power structures influence everything we do. A major shortcoming I see in software today is the default of a top-down hierarchy being the only way permissions etc work, which is mimicking authoritarian power and influences how people self-organize. DEIA is the antithesis of that, and a guide on how to move past that legacy. We need novel collaborative workflows and ways to talking about power constructively. No community is a flat egalitarian utopia, and that’s not a useful goal. The goal should be to transparently show you the power so it naturally becomes more accountable & aligned.

3. Communities require trust, which requires the investment of time between individuals. Therefore, you cannot create community that is frictionless, fully automated, or infinitely scalable.

This is an idea I’ve been considering in many contexts — work, community, friendships. Trust is the core fabric of any group, and there’s no shortcut to it. So, the idea we can fully automate a community into existence with AI or similar tools isn’t just doomed to failure, it’s missing the point entirely. It’s not even a “human in the loop” problem — we’re not talking about failsafes or quality. It’s that time investment is the currency of trust, so if you eliminate time investment, you cannot create trust. A community with only authority and no trust is the playground of fascism.

4. Every community is unique and its software should reflect that, but community management should not require programming plugins or themes.

This was a hard lesson I learned from managing Vanilla Forums for so long and being embedded in the WordPress ecosystem. Community management is its own skill, and the overlap between that skillset and product/programming skills is incredibly narrow. We need to build a system that stands on its own and collaborate on a core feature set that cleverly solves many uses without creating an overly complex plugin soup system that breaks in unexpected ways. It’s much harder to gain traction this way, but I now believe a plugin system limits your upside & cripples sustainability after you do.

5. The open Web is critical to the future of humanity and is best supported through standards-based interoperability, strong data privacy, and platform transferability.

We need Web-based software first and foremost, and we need to lean into open standards & privacy. Everything I have done to the contrary in my career (Facebook Login, Google Analytics, myriad vendor API integrations, platforms with no migration path away, and so on) I’ve eventually come to regret. Every other platform rug-pulls at some point; every other platform has unsolvable hierarchical control problems. I’m putting a stake in the ground and say “do it with the Web” so we’re clear about those risks.

These are dense, layered beliefs.

I hope it’s clear that I’m prioritizing governance & ideas over technical excellence. When I evaluate a library, I want to consider whether it’s run by yet another BDFL (benevolent dictator for life) that has quarterly financial goals to meet as much as whether it technically does what I need. If you want to build a different type of sustainable community software, you need community governance in its entire stack, not just the final app.

I want to resist the temptation to “do it right” by reinventing the wheel because the existing wheel has 10 spokes and I need a 12-spoke wheel. I’d rather shake hands with the wheel maker and make sure we’re on the same page about the importance of people. When I write code, I want to write it foremost for the other humans reading it, not the machine compiling it. When I design a community feature, I want it to serve these beliefs and the people who agree, not quarterly revenue goals.

I don’t believe software exists today that follows all these beliefs, but I found an established community software project willing to try with me.

Fifteen years after I joined a couple of Canadian entrepreneurs to ride a wave of “next-generation” community software, I believe it’s time to take another big swing.

Related: Collaborative Authority