my avatar image

A year of making open source web community software

May 12, 2022

I've been building an open source web project focused on community software with Hamilton Reed (Twitter, GitHub) fulltime for a year. We @feltcoop recently started a monthly newsletter and (gulp) a podcast called Toolmakers Forum. I plan to write about its ideas on this blog.

The software:

‼ please note this pre-alpha software is not yet secure, so use it at your own risk and please don't pipe it data that you don't want public (also, we don't yet operate a public instance)

What are these underserved niches?

Fullstack modding is key to why I want to work on Felt, but it has a lot of unknowns and we need to implement it to understand it. For devs, it means we'll have open source components, clients, and servers that are designed to be extended and swapped out. For endusers it means:

We think of Felt similar to a smartphone or Swiss army knife: it performs well for many tasks and often it's all you need and want, but sometimes you need more specialized tools instead. The current featureset is a single app with chats+forums+todos+more that's perhaps less slick than each but far more powerful in 1, supporting both realtime and asynchronous communications, and collaborative everywhere, and we'll prioritize interoperability to make Felt fit into workflows it doesn't know about. (this is complicated, see below for more on interop)

We're calling Felt "a tool for building and maintaining communities".

We'll provide defaults and templates, and users can modify the software for their own needs. We'll support simple and scalable static web publishing like blogs and RSS feeds, along with the tools to make hobby-grade realtime social experiences and games.

"hobby-grade" is how I like to frame it today, but "for srs Professionals" is an eventual target; it's still early and I don't want to overpromise. Security is going to be a challenge, so treat it like a dangerous toy for now.

It's a big set of goals, and we think we have useful contributions particularly around UX. We think we see an opportunity to hit a sweet spot for small communities with our set of design and tech choices. Our 9th and 10th podcast episodes go into more detail on the main ideas.

The projects:

We have a handful of software repos, none of which are yet production ready:

In summary:

As software users, we want easy-to-use and powerful tools that we can tailor to our needs.

As platform users, we want a professional, trusted, incentives-aligned operator, and we'll pay for it.

As service providers, we want to build reliable orgs to operate infra to help users succeed.

As devs, we want to build great software for people, prioritizing endusers over operators.

As toolmakers we want to help users bring their own visions to life and support beneficial relationships with technology.

The idea is to make the software we want to use, at the company we want to work for, providing the service we want to pay for.

more at

Wait the blog post isn't done?

I'm having difficulty summarizing the project: it's big, there's many unknowns, and my summarization skills could certainly improve. I'll write more followup blog posts, hopefully more coherent than this one, but for now I'll add a few more thoughts below.

Everyone can be a toolmaker:

Instead of being limited to filling digital boxes designed by tech companies, anyone should be able to design their own box. Or forget boxes even, we're in the digital realms. We see examples of what's possible in all sorts of products over decades, especially in games, and I believe there's fresh opportunities to do this with web tech.

We want to build software tools that anyone can use to explore the vast terrain of collaborative experiences, so you could take a larger role in designing your media, if you want. A key here is to make a great media sharing UX, so some % of people make and share useful and cool stuff, and everyone benefits.

Sharing spaces with others:

One aspect of community software that's full of interesting opportunities is how to govern shared spaces: things like exercising power, communicating and enforcing rules, nudging norms, making collective decisions, scripting governance processes over time, and so on. Each group of people has distinct needs.

We're collaborating with PhD student Jane Im ( on designs including research-backed user-driven governance. Her paper "Yes: Affirmative Consent as a Theoretical Framework for Understanding and Imagining Social Platforms" (, which credits The Consentful Tech Project, has been a major source of inspiration for how we think about designing software.

Our perspective as toolmakers is that we'll attempt to support a wide range of possibilities, from traditional moderator setups to democratic control and much more, and provide templates and guidance to help communities achieve their goals. We'll give this a lot of attention before beta, but I suspect the delightfully good stuff is 1-2+ years away, maybe using standards that Metagov is developing. I'm also keeping related projects CommunityRule and PolicyKit in mind.

Business and ownership:

business model: no ads, no crypto, free and fully open source; users pay for service and if it's sustainable we'll creatively subsidize users for more equitable access

ownership/control: self-funded worker co-op with plans to become a platform co-op, is forprofit but co-op could choose to become a nonprofit

How does this business model work, giving away the software for free? Because the product we're selling isn't the open source software, it's the service and network.

We think we can reach sustainability at usercounts that look *very* small compared to a typical ambitious startup, and we don't feel threatened by other service providers taking some or most of the pie. The terms we're competing on don't require that we have a monopoly on hosting the service.

So what does success look like?

In the not-too-distant future, I'm excited to find and fund three more colleagues and turn our Temporary Benevolent Dictatorship into a real co-op. (5 is the number required to form a Colorado cooperative; Hamilton lives there and although we're a remote team, it has some of the best-developed cooperative laws in the United States) If you're interested in joining a team like this (it's not for everyone) we'd love to hear from you.

I would consider it a great success if one day, democratically selected experts make the difficult operational decisions and I, web developer, get to stick to webdev.

And success today? Structuring incentives to create the best software we can and executing capably, while enjoying the process, focusing on principles, and building good relationships.

Tech notes:

We tried to be thoughtful about our tech stack given the assumption that we'll be in the JS+node+npm ecosystem. We chose the web because we think it's the best way to deliver the UX we want to the most people, and we chose these specific technologies because of fit, familiarity, and productivity.

on the shoulders of giants on the backs of turtles:

the Web has vast unrealized potential

Node and TypeScript are productive

Postgres and nginx are solid

Svelte, SvelteKit, and Vite have been a fantastic set of tools for making UIs. We don't yet use some of SvelteKit's flagship features like endpoints, but we feel productive and delighted working with it, and its flexibility is a wonder. We've been deprioritizing full SSR but it's a relief to know it's there when we're ready for it. It's amazing how much of the load SvelteKit lifts from our shoulders.

customizable and extensible:

Both the server and clients are open source and our APIs are open, so clients can be modified or created from scratch. We'll try to maximize the freedoms of users and developers, but security and performance are unfortunate constraints and sometimes buzzkills :\

Our client has a thickness optimized for UX over long sessions, which means a lot of JS and client-side caching, and thanks to SvelteKit we should be able to deliver good experiences in many cases with fast loadtimes and minimal JS.

scaling (and not):

Our focus on "small communities" relates to a potentially deflating fact about our software: it doesn't scale to large numbers of people or some kinds of heavy load. Felt can't be the best solution to all problems, and tradeoffs are unavoidable. We're optimizing to quickly iterate on social experiences with human-scale groups of people on a single machine with web tech. The limits may appear restrictive compared to the infinite cloud worlds, but these tradeoffs give us a simple, highly productive environment that's powerful in the small, and maybe small communities are good too.

Today, felt-server supports only @sveltejs/adapter-node – we'd like to be compatible with as many SvelteKit adapters as possible, giving operators access to more scalable cloud backends, but that's a distant hope.

We should be able to support non-realtime usecases that scale to more users like blogs and similar web publishing, much for free thanks to SvelteKit. We're prioritizing flexibility and UX over the ability to handle massive amounts of data, and we'll improve various kinds of scaling over time.

Even though our code isn't pushing the boundaries of performance and enterprise readiness, we're trying to write it modularly and with good principles, so hopefully it evolves gracefully and enables better tools to be built on its foundations. (for example, we have a unified serializable event stream for the client and server API that works for frictionless realtime broadcasting and already has bare-but-never-out-of-date docs – we're cutting a lot of corners but also investing a lot in tech up front)

interop and decentralization:

Giving users choices is a principle I want to adhere to, and that includes cooperative interoperability, but we're a 2 person team with limited resources trying to deliver a specific UX. Today this means we have a centralized Node server, and a future possibility is to support decentralized backends like ActivityPub and Matrix.

We're trying to follow the ActivityStreams vocabulary spec that's used in the fediverse and Mastodon (and I made some unofficial docs), but we have our own bespoke client-server protocol that works over http and websockets. I think we can generate OpenAPI schemas from our source of truth, which would give us greatly expanded access to existing tooling.

We try to use JSON Schema where it makes sense, and we support both RESTful-ish http endpoints and websockets using JSON-RPC 2.0.

We want to be good citizens of open standards, not just do our own thing off in the corner, but we have very specific ideas of what we want to build for small communities, and decentralized tech isn't optimal for today's goals. I personally think decentralized technologies are the future and I would love to help Felt be compatible with standard protocols once we have our desired UX.

"decentralized" means a lot of things, and while I think it's a broadly inevitable future, I believe the rather important details of ownership and power have yet to be determined, and my hope is that justice-oriented movements like platform cooperatives and the DWeb do better than the rent-seeking and financializing that dominates today; I want to own the digital ground under my own feet, don't you?

Ok cool?

find us @feltcoop on Twitter and GitHub, read our monthly newsletter, and look a podcast