One size fits none: let communities build for themselves

A little under twenty years ago, I stood on stage at the University of Brighton, in England, at our Elgg Jam event. Elgg was the open source social network I’d co-founded; Brighton used it to become the first university in the world to roll out a social network campus-wide.

I was giving the keynote talk, explaining what we’d include in the next major version of the platform. I built up anticipation, hamming it up as the audience — many of whom had built social networks with tens or hundreds of thousands of users — waited for what I had to say.

I moved to a blank slide.

“None,” I said. “The next version of Elgg has no features.”

Genuinely, there were gasps. I don’t think I’ve had a similar reaction at any talk I’ve given since. Years later, one of the attendees told me it was a mind-blowing moment: one of those sessions that immediately changes your perspective.

I went on to explain.

Instead of releasing a rigid social network out of the box, we recognized that for communities, one size didn’t fit all. Instead of giving everyone the same configuration, the same interface, and the same collection of tools, each community owner would easily compose their own combination of functionality and experience in order to best fit the community they served. By then, Elgg had been translated into 80 languages and there were a ton of plugins from across the ecosystem; there was a lot to configure a site with.

The underlying point was that a social networking platform existed to support a real human community, and needed to be responsive to its needs. How could we, as platform developers, possibly know what every community needed? We couldn’t; we didn’t. It was better to put that power in the hands of people who did.

Since that talk in September 2007, we’ve seen a lot of social networks that were one size fits all: Facebook, Twitter, Instagram, TikTok, and a raft of others. Each has forced communities to adhere to its own design assumptions. Every platform’s user experience is rooted in the cultural and intellectual assumptions of its development team. A rigid user experience means that needs that aren’t in line with its team’s worldview may be ignored.

That’s not a trivial gap. Some communities have specific requirements about identity; others have particular cultural sensitivities that need to be incorporated in an approach to trust and safety. In Myanmar, Facebook (which is based 8,000 miles away in Menlo Park, California) ignored local needs and community dynamics to the extent that it’s been accused of facilitating the genocide against the Rohingya people.

For centralized, proprietary platforms, there have been few options. Even for platforms like Bluesky and Mastodon, which are based on open protocols and can be forked and self-hosted, changing the interaction model and user experience has traditionally required a significant amount of development work.

If only there were some way to make that process easier.

Custom code is easier than ever

One of the most interesting developments this year has been agentic coding’s elevation from interesting tool to code-producing productivity workhorse. People I know who have been writing software for over thirty years are now using LLMs as their full-time coding engine. My friend Jesse Vincent, who has written open source software and managed the Perl programming language, now spends his time on ways to bring senior engineer-level thinking to LLMs. Simon Willison, co-founder of Lanyrd and creator of Datasette, spends much of his time exploring, defining, and analyzing the space. If LLMs sucked at this, they would say so. But they don’t, and instead these two veteran engineers have gone all-in. So have many thousands of other engineers.

In a world where custom code can be created far more easily than it could in the past, communities can more easily build bespoke spaces for themselves. There’s no need to adopt a one-size-fits-all platform — even an open source one — when you can ask for the exact features you want. Beyond existing tools like Claude Code, you can imagine tuning an AI-powered system specifically designed to help community leaders create customized platforms.

What would be needed then are agreed-upon rules about how community platforms behave: how they communicate with each other, how they integrate a user’s identity, and how they work with services for moderation, flagging, and other trust and safety necessities.

There’s a word for agreed-upon rules for how software communicates with each other: protocols. And in a world where anyone can spin up their own software, they’re more important than ever.

Protocols for parties

The web already has protocols and standards. Web pages travel over the HyperText Transfer Protocol (HTTP) and serve HyperText Markup Language (HTML). If anyone wants to build a new web browser, they don’t have to ask anyone; they just need to follow the HTTP and HTML specifications (okay, and CSS, JavaScript, etc etc — but these all follow the same principle).

Just as the web is built on open protocols, the next generation of social platforms is too. ActivityPub describes how two different community platforms can send messages between each other on behalf of their users. Authenticated Transfer Protocol (ATProto) defines how users can use and move their identities and provides a shared data layer. ActivityPub is used as glue between Mastodon, Ghost, and Threads; ATProto is used by Bluesky, Blacksky, Eurosky, and applications that sit on top of them. In both cases, just like HTTP and HTML, anyone can build a new community platform that uses them — and that therefore will be immediately compatible with all the other community platforms that use them.

These protocols have been around for years. But now that software itself is becoming cheaper to produce, and everyone can build their own applications that are right for them, the center of gravity has changed. Whereas previously open protocols were the co-ordination layer for many instances of a few applications, now they’re the co-ordination layer for an exploding ecosystem of more custom applications, each of which could be installed many times over.

Previously, libraries, modules and plugins were the building blocks of software. Consider what we were trying to do with Elgg, or what the WordPress project continues to push on: a core codebase that you can extend and configure by downloading plugins and themes from anywhere. Those plugins will still be a part of the ecosystem, but new plugins can be generated in hours or less. And increasingly, the existing ones will be configured for bespoke needs, too.

That’s a lot of custom codebases. By default, they’re all siloed away from each other. If one person builds a community for a neighborhood over here, and another person builds a community for an affinity group over there, there’s no way for them to intersect. People have to find them, sign up for them, and interact with them separately — and every new community has to start with zero users.

But if we make drawing on open protocol specifications as easy as pulling an open source library or a WordPress plugin, the definitions for how all these bespoke apps and communities talk to each other become the new shared building blocks. With them, each new codebase is part of an expansive web of applications and communities.

Making it easier

There’s more we could do to make this world possible.

Today, software often relies on something called a package manager to easily incorporate libraries. You can imagine a spec manager that does something similar for agentic development. Tell it to import ActivityPub, and boom, through a combination of instantly-applied new skills and cleanly-written specification guidelines, what you’re building is compatible with the Fediverse.

Just as libraries get added to a package manager today, new specifications could be added to a spec manager in the future. This would catalogue all protocol specs from across standards bodies — and, of course, anyone could publish their own, just as anyone can publish an open source library today. These become software dependencies.

And we could use domain-specific tooling that makes building software easier for non-engineers. A community platform builder would help community leaders create software to support their work, but hide complex development, debugging, and infrastructure considerations. Despite the abstracted, walled-garden nature of this kind of interface, open protocols would mean that the software could be deployed to a choice of provider, and its data wouldn’t be locked up inside it.

If it’s not obvious yet, none of this is tightly-bound to agentic development. If you hate LLMs or just want to write everything by hand — both reasonable positions — there’s nothing stopping this kind of infrastructure from being useful for you, too.

What’s still to come

We have established protocols for identity and communications between systems, but there’s more to running a community. For one thing, a community leader typically wants to make it safe: moderation, content flagging, and other abuse protections are vital. Every community needs to tend to its culture; making it welcome to more vulnerable users — the people more likely to be the subject of abuse — is an important step towards that.

Part of the point of having bespoke community platforms is that these value systems may be different from community to community, and the signals of abuse may be specific to them. Facebook failed Myanmar for exactly this reason. So these communities need to handle their own trust and safety.

But dedicated open protocols for trust and safety systems would allow these community owners to work with third-party platforms that might provide safety tooling and frameworks. It could also make it easier for multiple communities with similar values to pool their resources around trust and safety. These communities could all connect, through open protocols, to a third system where moderators can review content and take action through one central interface.

Overall, it’s the human stuff that rises to the top when code becomes more of a solved problem. Rather than considering how to build it, or where to obtain it, we can finally spend most of our time on the more important considerations: what is needed, why and for whom. We can use our own cultural norms to define the answers to these questions rather than accepting one-size-fits-all approaches from people in Menlo Park.

Which brings me to one last thing.

How we generate the code matters

While I don’t think these principles apply solely to agentic development, I believe that’s how they’ll most often be used.

The LLMs we mostly use are centered on Silicon Valley culture, with Silicon Valley assumptions. Their inherent biases, drawn from the source material the vendors have chosen to use to train the models, are well-documented. The vendors themselves often work with government, the military, law enforcement, and immigration, which may sometimes be at odds with community values. If we are truly to use this technology to build community-first software, the technology itself must be values-aligned with the community.

Writing code by hand, depending on the developers involved, fits this ethical standard. But we need LLMs that reach that bar, too. That’s most likely to mean grassroots models that are in themselves designed to be more community aligned, and whose source material is more likely to be ethically acquired.

This work is already being done. Small Language Models are being used to revitalize Indigenous languages. The Mozilla Data Collective is enabling more consensual, ethical, representative training data. These are the kinds of tooling efforts that will support community-aligned development, alongside the open protocols that will govern how generated software works together.

Many people are hard at work with the intention of supporting communities far better than the last generation of social media. Simultaneously, there’s been a resurgence in open protocols, and the rise of LLMs that can build software on our behalf. Together, these trends mean there’s so much more we can do.

In particular, moving away from the assumption of one-size-fits-all scale and leaning into the idea of small, culturally-aligned applications and tooling will enable us to better support communities that are far away from the norms and assumptions of Silicon Valley. It will be hard. But it’s a journey worth taking.