Open source leadership resolutions for 2024

Close up on a half-burnt sparkler with white sparks on a gray-green background.

We’re almost at the start of a new year, which means lots of people are making resolutions. This includes people who have leadership roles in open source projects. While I haven’t used my gym membership in a year and a half, I have a few resolutions that might be easier to keep. If you’re looking for some inspiration, here’s what I’m thinking about for 2024.

Make a succession plan

The best time to create a succession plan is the day you start the project. The second best time is now. Even if you love the project and you can’t imagine yourself ever not working on it, you need to imagine not working on it. At some point, you’ll lose the interest or ability to continue maintaining the project. If you have a plan ahead of time, it becomes much easier to manage the transition. It may seem morbid, but there’s no guarantee you’ll be around to set things up for your successor.

Be honest about project state

Supply chain security is becoming a more important consideration in the software industry. Whether you asked to be or not, your project may be a part of someone else’s supply chain. This can result in a lot of requests, without the matching funds to support them. This is just one reason that it’s important to be honest (including with yourself) about the state of a project. If it’s abandoned, say so. You can always bring a project back from the dead if you choose, so it’s better to make the decision earlier instead of pretending you’ll work on it Real Soon Now™. If someone chooses to incorporate a clearly-unmaintained project into their software, that sounds like what I call a “Them Problem”.

React with empathy

Sometimes the bug reports you get are filed in the heat of the moment. They may have lost data or at least embarrassed themselves as a result of a bug. Even if they were using in a way that’s clearly Doing It Wrong™, you can treat them with empathy. This isn’t to say you should tolerate abuse, because you absolutely should not. But you can be kind to them, and look for opportunities to improve your guardrails.

Don’t try to do too much

I’m ending the resolution list here because while there are a lot of things to fix, I can only do so many at a time. I’m really bad at over committing, so I don’t want to start off by over committing on my resolutions.

This post’s featured photo by Cristian Escobar on Unsplash

Ben works on open source strategy at Docker and was previously the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.