A year of making open source web community software
May 12, 2022 – updated Nov 28, 2022
I've been building an open source web project focused on community software with
Hamilton Reed
(Mastodon,
GitHub) full-time for a year,
since April 2021. It's
been two and a half years since we first met in December 2019 and started self-funded part-time
work on preproduction and peripheral projects. We recently
started a monthly newsletter
and a podcast produced by Hamilton called
Toolmakers Forum. I plan to write about
Felt's ideas on this blog.
The main software felt-server:
- is a toolkit and server for building and maintaining communities, publishing to the web, and collaboratively working with information. The main UI looks like Discord and Slack on the surface, and it has aspects of a content management system and knowledge management software in a collaborative environment. We're aiming for a batteries-included, deeply customizable experience with a small footprint, that feels familiar and surprisingly powerful.
- is designed for small communities
- is multipurpose, so the same toolkit can be used for many kinds of communities and websites
- is open source and designed for fullstack customization, which means devs and end-users have proper access and power over their UX and systems and code, and we bridge more of the gap between programming and using
- is currently pre-alpha, and we hope to reach alpha in Q1 2023
‼ 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)
Fullstack customization 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. (name pending - maybe "web engine" is a helpful framing) For devs, it means we'll have open source components, clients, and servers that are designed to be extended and plugged and swapped. For end-users it means:
- a comfortably familiar environment that looks like existing social apps, but more deeply customizable and flexible
- a composable text language with a rich vocabulary that can be used to write chat messages, blog posts, forum replies, todo items, and so on, and also construct both social spaces and the entire client UI
- easy-to-use plugins, mods, modules, etc, made by us at Felt and hopefully a community of developer-users, and clear paths to learning the technical skills to make your own stuff
- programmery-things like recording events and authoring scripts, and composing them with things like governance processes (e.g. "execute this script if the vote passes")
We think of Felt similar to a smartphone, in terms of packing many tools into one object: it performs well for many tasks and often it's all you need and want, but sometimes you need more specialized tools for a task. 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's server "a tool for building and maintaining communities".
- easily selfhosted, targeting the low end VPS tier (~$4/mo)
- uses tech like Postgres, Node, TypeScript, Svelte, and SvelteKit
- we want to use it personally and make stuff with it
- we're using it professionally to build itself under democratic control
- the software project will be a nonprofit and we plan for the operator to become a platform co-op
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 realtime social experiences and games.
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:
- @feltjs/felt-server – the community software that's both deployable and available as a library on npm
- Felt.social – an aspiring platform co-op to support communities, operates instances of felt-server
- @feltjs/felt-ui – a library with styles, Svelte components, and other code for building things from simple websites to realtime interactive multiplayer experiences (eventually this will include much of what's currently in @feltjs/felt-server)
- @feltjs/felt-template – a static web app template with SvelteKit, TypeScript, and Felt for quickly creating new projects - in the future it will support quickly creating a custom server project, too.
- @feltjs/gro – a toolkit that extends SvelteKit and Vite with things we find useful for making web apps; it's used by all of our other projects
- @feltcoop/dealt – we haven't touched it in a minute, and there's not much there yet, but it's a fun side project to showcase how the software can be used
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, usually prioritizing end-users 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 github.com/feltjs and github.com/feltcoop
Wait the blog post isn't done?
I'm having difficulty summarizing the project: it's big and there are many unknowns. 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 digitized. 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 candidate Jane Im (imjane.net) on designs including research-backed user-driven governance. Her paper "Yes: Affirmative Consent as a Theoretical Framework for Understanding and Imagining Social Platforms" (consentful.systems), 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
Felt.social (@feltcoop@github.com) is a separate entity from Felt the software project (@feltjs@github.com). We haven't done the legal work to make it official, but the Felt project trademarks and domains (like the green heart logo and felt.dev) will be owned and managed by some kind of nonprofit entity, not the Felt.social co-op. The co-op is just one stakeholder from the perspective of governing the Felt project. This is a commitment to the public open source community that these are community assets.
Felt.social business model: no ads, no investors (so we need a real busines model), no crypto, and the software is free and fully open source (permissively licensed, not "open core") - users pay for service and if it's sustainable we'll creatively subsidize users for more equitable access
Felt.social 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 (this seems likely? we just don't know yet, and we promise we won't sell out our community for a bigmoney #exit)
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?
The goal for sustainability is first to pay our own bills, then find and fund three more colleagues and turn our Temporary Benevolent Dictatorship (via CommunityRule) into a real co-op. Five is the number of people 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.
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 is everywhere and has vast unrealized potential
Node, TypeScript, Postgres, nginx, and Linux are productive and solid
Svelte, SvelteKit, and Vite have been a fantastic set of tools for making UIs. We don't yet make full use of SvelteKit's features, but we feel highly productive and literally delighted working with it, and its flexibility is a wonder.
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 a powerful and low-latency 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 or zero 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.
- quickly iterate on social experiences with human-scale groups of people
- on a single machine (running a server and local database with light resource requirements)
- with web tech (this puts us in a particular ecosystem of software)
The limits may appear restrictive compared to the infinite cloud worlds that can host a global social network, but these choices and tradeoffs give us a highly productive environment with low resource needs that's powerful in the small, and maybe small communities are good too.
Today,@feltjs/felt-serversupports 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 we haven't worked it into our roadmap
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 gamedev-level 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. We're cutting a lot of corners but also investing a lot in particular parts of the tech up front, trying to plan for the long run to maximize power for the user.
interop and decentralization
Giving users choices is a principle I want to strive for, 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 with a lot of homemade solutions. One of my long/medium-long term goals is to support at least one federated/decentralized standard like ActivityPub.
Given Felt's small-scale design and selfhostability, it may help to think of it as "polycentric", where each community is a silo of self-governed data, and a service may host one or more communities. In combination with clients that connect to multiple services, I think "decentralized" is an appropriate description, but not in the way some people want. I won't be satisfied until Felt can federate with the wider world, especially for user identity.
In our data system, 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, and our database
tables don't map to ActivityStreams vocabulary, only Entity objects do. We could generate
OpenAPI schemas from our source of truth, which would give us greatly expanded access to existing tooling,
but we have no plans for that yet.
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 detached from open ecosystems, but we have very specific ideas of what we want to build for small communities, and federated tech isn't optimal for today's goals. I personally think decentralized technologies are the future and I would want to help Felt move with the times.
"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 (or at least co-own) the digital ground under my own feet, don't you?
Find us
- @feltjs on GitHub & npm
- @feltcoop on GitHub, npm, Twitter & YouTube
- read our monthly newsletter and look a podcast