Open source software is used by organizations large and small around the world. And it's become very popular in the tech industry.
Many people want to be involved in this open side of tech, and luckily there are many different ways to contribute.
Still, open source can be scary at first sight. My first official contribution was during Hacktoberfest 2021, and even after that, it took me while to really feel welcome.
The open source community helped a ton, and it's the route I would advise any new techie to take – get involved with the community around a project you care about.
In addition to being a contributor – making updates to open source code bases, updating documentation, and so on – you can also eventually become a project maintainer. Maintainers are responsible for the thrill you experience when your pull requests get merged.
As daunting as it is to become a first time contributor, it is also quite scary becoming a first time maintainer. So in this article, I'll discuss some of the soft skills project maintainers should cultivate to be successful.
A Little Background
After open sourcing a project very close to my heart, I was lucky enough to gain some much needed experience. I also held a Twitter space with some amazing folks, and they had much to share as well. Hence, this article.
I won't say I am an expert, but to successfully scale an open source project, no matter how big or small, there are certain skills you need to have. And some of these I didn't pick up until after I had been a maintainer for a while.
Skills You Need to Maintain an Open Source Project
Develop Good Time Management Skills
On day one of releasing the project, my email was flooded with GitHub notifications.
I was happy people where checking the project out, but it was too much for me to handle. I was putting off work to attend to issues, assigning, labeling, merging pull requests, fixing conflicts... It quickly became too much to manage. I needed to allocate time and set boundaries.
If you are running a big project, notifications are probably nothing new. If you're running the project alone (like I was at that point), it is way worse.
Putting aside specific time to attend to GitHub tasks was the best way out. It could be in the morning before work, or after work, or only on weekends, depending on what works for you and the project.
Be Patient
I hear people advise contributors that they shouldn't spam maintainers if those maintainers can't attend to their issues/pull requests in time. This level of understanding should go both ways.
Contributors also have lives. If a contributor claims an issue, it is important to give them time to actually submit a pull request. Open source is fun (we've agreed on that already, but just for emphasis), but some people can only contribute in their spare time.
If a claimed issue is taking too long to address, a subtle reminder is fine. Constantly reminding a contributor that they need to submit a pull request could be off-putting, and it isn't a good look for you or your project.
On some rather large projects, however, a time frame is given to contributors who claim issues. I've seen cases where a contributor has about seven days to raise a pull request. While this is understandable because of the fast paced nature of these projects, I personally feel that it's too much pressure, especially for new contributors.
Be Empathetic
For me, this is the most important skill. I can remember my first open source contribution. The joy I felt when my pull request got merged and the immense support from the community were wonderful.
Think of this when you merge pull requests. It could be the contributor's first time too. I try to close off pull requests with a message other than just 'LGTM'. It can be as simple as throwing in a bomb emoji, and thanking them.
People come back to a place where they feel welcome.
Be Firm
This can be hard, but it's also important. You won't merge every pull request that is opened, and that's a fact. But abruptly closing off a pull request without justification isn't exactly good practice either.
If a pull request is too big, or it doesn't add to the project like you would've wanted, it is okay to close it. But do not be afraid to kindly explain to the contributor why it can't be merged. Don't leave a pull request open forever because you feel guilty about closing it.
People can be more understanding than you think if you give them simple common courtesy.
Work on Communication Skills
Collaboration is the basic foundation of open source as a whole. And to collaborate effectively, you need to be a good communicator.
Having people come in and work with you on your project is cool and all – but if you can't properly communicate with these people, you'll end up with a closed open source project (if that makes sense).
Collaboration doesn't have to be you spinning up some huge discord server for the project. It could just be you sharing messages in your code reviews.
If the comment sections under your issues are too small, then GitHub has a discussion tab for each repository. This is a great place to spin up new ideas and start some great connections.
You never know whom you might meet!
Listen and Learn
After open sourcing my app, I've probably learnt more React than I would've if I was watching tutorials and building in private.
Smart people will come along and open your eyes to ideas that you couldn't have thought of on your own. My project has improved so much, mainly because I wasn't afraid to try out new things.
The community wants to help – so let them.
Cultivate a Community Spirit
Someone recently reached out to me, saying they wanted to get involved in reviewing pull requests because it was fun. They aren't officially a maintainer, but I would like to think that they enjoy being a part of the project.
Building an open source project is a community effort. And as a maintainer, you will need that community spirit.
You need to be excited with what you do. Collaboration should be fun. You are happy that the contributor added something, but let them also be happy that they contributed.
People love good, honest feedback. And it also helps you build up your little community.
Be Responsible
If the open source project is your idea, then you're the pioneer. If you decide to be the lead maintainer, be the lead maintainer. Be reliable, and most importantly, be present.
Even if you are a supporting maintainer for some big project, it is good to show that you know what you're doing and that you're committed to the project.
Some projects go stale because the maintainers stop responding to issues and pull requests. It's true that life catches up to us sometimes. If you decide to commit to a project, though, it's important to always show that the project is alive.
But how? Well, everything leads back to collaboration. Keep your collaborators involved and they'll help you out.
Be Nice and Welcoming
People are coming from different backgrounds to check out your project. Whoever they are, they won't come back if their first experience was a mean maintainer, whose project had poor documentation.
No matter how easy you make things, expect questions. Be ready to answer these questions. Point people to the right resources, no matter how obvious the solution could be.
If a contributor is having a hard time, check your documentation. Most times, it's not them, it's us (pun intended). The README might've skipped some steps, or a screenshot wasn't clear enough. Instead of telling them off, point them in the right direction and update your docs if need be.
Conclusion
All in all, being a maintainer is hard work. Whether you're going solo on your project, or working with other maintainers, the goal is the same: collaborating to build great products.
Projects with poorly structured management and responses are one of the main reasons some people feel discouraged when it comes to contributing to open source.
The skills I've covered here are mostly based on personal experience, but I hope they help anyone maintaining a project, or thinking of being an open source maintainer.
If you want to check out my open source project, you can do so here.