Planning open-source work

One of the things that I find the hardest when building open-source software is planning the work. On one side, there are all these new features and improvements that you’d like to build. On the other side, there are PRs to review, tickets to triage and prioritize, and questions that come up. Leaning mostly on the former is not great because users and contributors feel ignored, but focusing solely on the latter isn’t good either because the project doesn’t evolve.

What to do then? I don’t know.

On Tuist, when I think about what to work on, many things come to my mind: there’s a new website design to implement, some caching issues that we need to tackle, documentation improvements that I’d like to add, functionality that I’d like to start building onto TuistLab… It’s too much. I’d like to do everything, and I end up doing nothing. The mental overhead causes paralysis. Working on one thing leaves you wondering if you should be working on something else instead. You feel bad because you are building something new instead of supporting existing users with the issues that they face. It’s tricky, isn’t it?

It’s something I’m trying to get better at, but it’s not easy. There are a few things that are clear to me though. There needs to be work on adding new features and improvements. I have a product mindset and I enjoy talking to users and turning that into solutions for them. The time that I invest into supporting users, I’ll try to time-box it. For example, I can tackle an issue per week and no more than that. I’d make exceptions if there’s a critical bug or regression in a new release. I have to say that in the area of support, we are lucky to have users, contributors, and maintainers helping there. Without their hands things would have gotten unsustainable.

So here’s the thing I’m thinking about going forward. I’ll focus on a project at a time and limit the support work per-week with exceptions. I’ll decide the project based on my motivations and needs and what’s important for users too. For example, I know caching of binaries is becoming and important feature for users. I’ll use GitHub projects to organize the work on projects and have a sense of progress. It’ll be helpful to involve others in a project I’m working on. And last and not least, I’ll continue engaging with users on Slack, GitHub, and Twitter. We need to continue building trust with Xcode developers because every new person that joins brings new ideas and challenges for us to solve.