my avatar image

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 (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:

  • is a toolkit and server for building and maintaining communities, publishing to the web, and collaboratively working with information. It has aspects of a content management system, knowledge management software, and other social and collaborative software. We're aiming for a batteries-included, deeply customizable experience with a small footprint, that feels familiar but is surprisingly powerful.
  • is designed for small communities
  • is multipurpose, so the same toolkit can be used for many kinds of communities along with standalone websites
  • is open source and designed for fullstack customization, which means devs and endusers 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. For devs, it means we'll have open source components, clients, and servers that are designed to be extended and plugged and swapped. For endusers 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, forum and blog posts, 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 (~$5/mo)
  • uses tech like Postgres, Node, TypeScript, Svelte, SvelteKit, and websockets
  • we want to use it personally and make stuff with it
  • we're using it professionally to build itself under democratic control
  • we plan for the operator to become a platform co-op and the software project a nonprofit

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:

  • @feltcoop/felt-server – the community software that's both deployable and available as a library on npm
  • @feltcoop/felt – reusable library of 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 @feltcoop/felt-server)
  • @feltcoop/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.
  • @feltcoop/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 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 github.com/feltcoop


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 (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 is a separate entity from Felt the software project. We haven't done the legal work to make it official, but the Felt software trademarks and domains (like the green heart logo, felt.dev and grogarden.org) 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 software project. This is a commitment to the public open source community that these are community assets.

felt.social business model: no ads, no crypto, 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 to be able to fund, and then find, three more colleagues and turn our Temporary Benevolent Dictatorship 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, and nginx are productive and 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 literally 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 and 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.

We're optimizing to:
  • 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, @feltcoop/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 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 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 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 with a lot of homemade solutions. One of my long/medium-long term goals is to support at least one decentralized standard like ActivityPub (my current interest) and Matrix.

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 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 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 & GitHub & YouTube, read our monthly newsletter, and look a podcast

my avatar image