Thoughts about my role with Actual

tags:: post
date:: Dec 29th, 2022

tl;dr I’m giving more power to the community and will not be responsible for merging and cutting releases.

Actual has been my pet project for many years. I was one of the first people to build a true local-first app with good cross-device syncing, and it birthed absurd-sql which had significant impact on the web ecosystem. I launched 4 years ago, built a modest customer base, and earlier this year open-sourced. I could write much more about everything I’ve learned.

However, today I’m thinking about my involvement with the project.

It’s clear I haven’t been as good at managing the open-source project as I wished. My approach was to take it slowly, allow the community to do good work, and with my limited time help shepherd that work in. I don’t have much time to do the work, but I wanted to protect the level of quality in the product and avoid it becoming a messy soup of decisions by committee. A BDFL, if you will.

While I’ve given people merge permissions, ultimately things block on me. I’m the only one that can cut releases. This was a feature, not a bug. I was still holding the product close to me.

But it’s clear that this isn’t working. And it’s time I come clean about a few things, and adjust Actual to meet this reality:

  • I just don’t have enough time to manage the product and community. I’m taking on more leadership positions with my job at Stripe, have 3 kids, doing heavy renovation work on our house, and more. I have a couple hours here and there, but I can’t even finish reviewing a PR with that time. Which means there’s no progress over long periods of time.
  • This may be surprising, but I personally don’t use zero-based budgeting anymore. I’ve used Actual with the “report” budget flag turned on [0] which enables a simpler budget strategy. I could write more about this, but I’m not the right person to make decisions for the overall budgeting mechanism anymore because I’m not personally invested in it.

This year has shown that there are many highly skilled developers interested in helping with Actual. It’s time to unlock their capability and spread out the responsibilities more evenly. Here are some changes I’ll be making immediately:

  • Giving @trevdor and @Matiss administrator rights to both actual and actual-server repos. They can give merge PR permissions for others if they wish, and will help merge PRs without any approval from me.
  • Giving @Matiss npm access to the @actual-app npm user so he can cut releases. Matiss has been a strong contributor and has been very interested in helping move things forward and I think he’ll do a good job.
  • @Matiss will continue to work on cleaning up the PR backlog and improving testing to so we can be more confident in changes.
  • @trevdor has developed a great mobile web version of Actual and I want them to merge it in asap. There’s a few bugs I want to fix in it, but I don’t want to keep delaying it.
  • I will take more of a backseat, and will be around to answer questions about code and look at any PRs that the maintainers want some advice on. I’m not leaving (see you on discord!), but will take more of an advisory role.
  • I will work on changing to represent the open-source version instead of the closed-source version.

Projects shift and change. All this is doing is making explicit what has already been the truth for a while, which lets us change the process to match it. And that will let Actual move forward.

Some new experiments

I’m a thinker and engineer at heart. I’ll always be experimenting with something. I do have some time for this, just as anyone should have time for fulfilling hobbies. I want more time for this, and this change lets me do this guilt-free.

There’s a ton of work building a product like Actual that customers use. Building a feature is a small part of it; testing it, documenting it, and fixing CI problems is a glimpse into everything else that goes into it.

I want to be able to explore without doing all that work (which I’ve been doing for years for Actual). I want to be able to hack on a bunch of stuff as an experiment without worrying about customers.

I’m still interested in finance apps, so I may work on an experimental fork of Actual. I’m not sure what this looks like yet, but I want to explore some ideas. I’ll likely send PRs and upstream some things that I fix in the lower-level systems.

Because I’ll be exploring again, I will also start writing a lot more. This means I’ll be writing and documenting the most complex parts of Actual like the syncing layer. Overall, this should be a good thing for Actual even though I’m not doing as much day-to-day work.

What this means for the existing closed-source service

Back when when I open-sourced Actual I said I was going to eventually shut down the closed-source service. This hasn’t happened yet because many subscribers wanted to continue using it until they figured something out.

The number of subscribers is down to around 300. I’ll be sending out emails to encourage them to close their accounts, but I won’t be shutting down the service. I will “freeze” it but continue to make sure it’s running. Subscribers will eventually move on and I’ll let them do that on their own time.

I’m not shutting it down like originally planned (yet) because there is very minimal work to keep it running.

[0] You can turn this on by adding "flags.reportBudget": true to the metadata.json file in your budget directory. This may be difficult on the web app, however, since it’s hard to directly access the files. You may be able to edit it directly in devtools.