5 years ago

Open source mindfulness

As a developer who likes and believes in the benefits of making our software open, I devoted a vast amount of time building open source libraries and tools in the open. It helps me learn and grow as a software engineer and experiment with things I can’t experiment with at work. In most cases, those contributions happen before/after work, when you need to care about other important things in life like family, friends, and health. Yes, those things are more important than work or open source, regardless of how much you like it.

One of the things that I find the most difficult of working on open source is doing it with mindfulness. I tend to get trapped by the joy and spend too much time thinking and working on it. As a result, I reach burnout points when I start wondering why I’m working on the project, what’s the value of it, what if I spend my time on something else, what if no one uses it. I even lose the motivation for it.

Getting burnout of doing open source work is not something new. If you do a bit of research you can find a lot written about the topic:

In this blog post I’ll walk you through some of the principles I’m sticking to to have healthier open source contributions:

Responsibilities

Open source is something that I do in my free time, something I’m not getting paid for, and which I do for fun. I dedicate the amount of time I consider healthy and balanced with other responsibilities. If I assume too many responsibilities and devote too much time to it, I stop having fun and start worrying too much about the project.

Vision

When I start an open source project, I write down what I’m aiming for with it. Which problem I’m trying to solve, the project, is it a short or long-term project? By doing so, I avoid wrong expectations, and I can use it to steer the project. For example, if it’s an experimental project that I don’t plan to maintain, I reflect it somewhere on the README.

Having a vision in the project is useful in discussions, where you need to justify why you are making individual decisions.

No

This is something I struggle a lot with because overall, I don’t know how to say no. Luckily, I’m getting better at this with some work. Some examples of when I have to say know are:

Goal

A project without a goal is hard to steer. When I work on a new project, and I tell people about it, I hear lots of different opinions along the way. People that like the project, and start supporting, people that don’t believe in the idea and think it’s not worth spending time on something like that. If I dreamed with the project and envisioned it, I appreciate the feedback a lot, but I’d like to prove to myself whether it was a wrong decision or something that brings value to developers.

I’ve sometimes been concerned about what other developers thought about the project and ended up losing motivation for the project.

Priorities

When I work on a new task, I prioritize either the ones that add the most value to the project, or which help achieve the next milestone to the project. Along the way, ideas and external contributions come out. I add them to a processing backlog and decide which level of attention they need. Concentration is gold nowadays, so even if I feel tempted to shift my focus to them, I try not to.

Those are some principles that I recently applied to have a healthy relationship with the open source project. It’s hard, especially when it’s something that I enjoy doing, but something that I have to do if I don’t want to burn myself out.

Are you an open source contributor/maintainer? I’d love to know how your relationship with open source looks.

About Pedro Piñera

I created XcodeProj and Tuist, and co-founded Tuist Cloud. My work is trusted by companies like Adidas, American Express, and Etsy. I enjoy building delightful tools for developers and open-source communities.