Hello. It’s me, Artist Formerly Known As Lead Maintainer of Foam.
You may remember me from such hits as “feverishly astroturfing a community around an early-stage open source project and then disappearing into the thin air without any kind of acknowledgement that anything had ever happened.”
This is that acknowledgement, followed by some thoughts about the future of Foam.
I’ve organized this article in three parts, so that if you don’t have time to read the whole thing, you can jump to the part that interests you the most:
Presently, I don’t presume to have any control over the Foam project.
In fact, I don’t presume to be able to speak for the project at all. In my absence, Riccardo Ferretti, who was one of the first people to contribute to Foam, has stepped in as the project’s lead maintainer. Since October, he’s improved Foam massively by his own code contributions, while also coordinating the work of others. By this point, Riccardo has put as much work into the project as I have, and as such has very much earned the right to speak for it.
A few weeks ago, Riccardo and I reconnected, and we’ve discovered our experiences maintaining Foam have been in many ways similar. In fact, in the previous paragraphs, when I’ve been using the first-person plural pronoun “we”, it hasn’t been just a rhetorical device. This piece was co-authored by Riccardo and I, and together, as the author and the maintainer of the project, we can proudly say:
Maintaining Foam sucks.
I initially created Foam with the goal of building the best networked note taking app. Right now it’s not even the best networked note taking extension installed in my VS Code. This might seem like a technical problem, but in our experience, the root cause is fundamentally organizational.
The way we’ve ran the Foam project is not productive in the short term, and not sustainable in long term.
We both want to make Foam better in the future, and we have some ideas on how to get there. But before we get to it, I want to take a self-indulgent detour to the past, and tell you how I came to walk away from Foam last September.
Here’s a quick timeline of my personal involvement in Foam
So when people ask, why did you stop working on Foam, the answer is easy: I had no choice in the matter. Almost overnight I went from wanting to spend my every waking hour working on Foam, to not being able to pick up my laptop and look at another pull request or Discord message.
Except it didn’t really happen overnight. In retrospect, towards the end of the summer my manic working schedule had itself become a type of raging against the dying of the light. The surest recipe for burnout is getting stuck in a loop where you have to expend increasing amounts of effort for diminishing returns. Every day you feel like you have to work harder, because the day before you didn’t achieve what you set out to do.
Burnout is a devious disease, because it becomes the filter through which you see the world. With Foam, I was building a Second Brain to store my knowledge, but what I needed was a second brain to observe my first malfunctioning brain, and tell it that it needs help.
It’s almost embarrassing to admit to having burned out on open source. When you burn out in your corporate career, you can shake your fist at capitalism, and people can relate. But open source?
“You did what mate? You turned a fun hobby into a responsibility and spiralled into catatonic depression over a few GitHub stars? Good job!”
As a maintainer of a popular open source project, it’s hard not to feel the weight of the collective expectations of the users, contributors and spectators of your project on your shoulders.
This is not a complaint about “entitled users”: Whether or not any individual contributor actually asks for your time, attention or care, you feel indebted to give it to them all. Well, I don’t know about you. I did, anyway.
Which finally brings us to something resembling a point:
An open source project can become just as toxic and stressful as a corporate workplace, when it’s poorly managed. I ended up leaving Foam because I had created a fundamentally unsustainable environment and then tried to sustain it until I no longer could.
In her excellent book, Working in Public: The Making and Maintenance of Open Source Software, Nadia Eghbal categorizes open source projects into four categories: federations, stadiums, clubs, and toys.
|High User Growth||Low User Growth|
|High Contributor Growth||Federations e.g. Rust||Clubs e.g. Astropy|
|Low Contributor Growth||Stadiums e.g. Babel||Toys e.g. ssh-chat|
What I wanted Foam to be was a Federation: A Populous, plentiful ecosystem, packed with diverse ideas loosely affiliated projects that would scale without central bottlenecks. Instead it became a Stadium, with a bunch of people running from the rafters onto the field trying to kick the ball to the direction they thought it should.
Where we ended up was the worst of both worlds:
We were trying to build an infinitely large platform in the middle of a ever-shifting ocean of ideas
For this project to ever reach its stated goals, this will have to change.
When I wrote Foam’s Principles, the goal was to build a software platform that would make it easier for people to solve their own problems, while contributing to a shared commons that everyone can enjoy.
What I’ve since learned is that:
Every successful software abstraction creates value by defining a set way of doing things, and provides tools to achieve them. In order to do this, they also define what is not possible within this abstraction.
Because we didn’t understand this early on, Foam quickly became a collection of loosely affiliated projects, ideas and approaches to note taking, sometimes incompatible with each other — far from the platform we envisioned.
To fix this, we have to draw some lines in the sand, so that we can make:
Riccardo and I have compared what we’ve learned, and we have decided to join forces to work on the following approaches.
Going forward, we want to be more intentional about:
At the end of this journey, foambubble/foam will be a leaner, and more centralized project.
This is not a closing of the gates. Quite the opposite. What we want to do is to build the infrastructure of the commons.
The stated goal of Foam has not changed. What we want is to enable Foam and its community of people to more effectively solve their own problems, explore a constellation of ideas, and contribute them back to a commons.
That requires being more than glue. It requires becoming a solid platform, and in order to do this, we’ll:
In the past, we’ve co-managed document linking and data visualization with other extensions, but for Foam to be able to build on top of its own platform, we need to reduce the amount of Lowest Common Denominator constraints set by supporting the projects and their nuances.
The next major evolution Foam will no longer require you to install other extensions for document linking and navigation. We aim to provide a more coherent and better integrated user experience out of the box, and instead of relegating key functionality to other tools, we’ll publish an API that’ll allow other extensions that want to build on top of Foam to access a common, consistent, model.
We believe these changes are going to make it easier for us to maintain the project and to eventually push Foam towards a 1.0 release.
We need to close some doors in order to open others.
You may have noticed this post is a little light on details. We have a good idea about the specific changes we are looking to make, and we’d like to present those on our next Community call on March 10th, at 10:00 Pacific, 15:00 Brazil and 19:00 CET.
None of this would matter without our community, and we want to give everyone who has contributed to the Foam thus far an opportunity to share your feedback. Both Riccardo and I recognize that, despite the challenges we’ve created for ourselves in maintaining this project, you have been an incredible source of energy, and we owe you a big thank you for your support and patience.
There are too many people to thank individually, and the full list can be found in the Foam repo.