.jpg)
n the first part of this mini series I spoke about how I got started in open source and what I get out of it. In this post I’ll be talking about the challenges. In some cases it’s not necessarily specific to open source and in others it might be specific to me or the projects I work on.
Before getting into it I’d like to just leave somewhat of a disclaimer that the tone of the post can seem negative because I’m writing about challenges. However the challenges are just one part of it and there’s a lot of nuance that’s hard to get across. People get into open source generally because its enjoyable and fulfilling; at the same time it’s important to know the challenges so that you can be prepared and try to avoid them.
Burnout
Burnout is probably the first thing that came to mind when you saw the title of the blog post and I think that's for a good reason. We all probably have some idea of what burnout is but here’s a definition I found online: "Burnout is a psychological syndrome emerging as a prolonged response to chronic interpersonal stressors on the job. The three key dimensions of this response are an overwhelming exhaustion, feelings of cynicism and detachment from the job, and a sense of ineffectiveness and lack of accomplishment". [1]
Most people I know have gone through some sort of burnout or know someone who has. Burnout isn’t specific to open source but I think that the nature of open source makes this a common challenge. Since open source work is mostly done outside of work hours it require a certain amount of personal time investment and as a project grows the hours needed will increase.
When you put everything into your work in an unsustainable way you'll eventually use up all your motivation. Back when I started with open source I happily spent most of my free time working on it since I was really motivated and enjoying it. I've always been bad at doing things in moderation and I easily over commit. This work ethic really wasn't sustainable and it became pretty unhealthy at some point.
When you put everything into your work in an unsustainable way you'll eventually use up all your motivation. Back when I started with open source I happily spent most of my free time working on it since I was really motivated and enjoying it. I've always been bad at doing things in moderation and I easily over commit. This work ethic really wasn't sustainable and it became pretty unhealthy at some point.
As a maintainer it's easy to feel like you have obligation to a project and feel guilt when you don’t find time to spend working on it. I often feel this way and it's something I struggle to overcome, especially more recently where I have found it more difficult to find that time.
Sometimes I feel like I was forcing myself to work on a project and it was creating resentment and negatively affected my mental health. When this happened to me I ended up just taking a long break and when you reach that point it’s often the only thing that helps.
Avoiding burnout is all about maintaining a good balance in your life. It's easy to get carried away when you get invested in a project, but it shouldn't feel forced.
After my own personal experiences with burnout I try to take a different approach. Here's a rough outline, that can hopefully help you, of how that looks:
- Outline a clear plan or roadmap for the project so that you can use your time on the project more efficiently,
- When it starts to feel like a chore and motivation is tough consider taking time away,
- Don’t feel guilty about doing nothing for a while,
- I don't promise specific deadlines any more since it creates unneeded pressure - try doing the same if you're going through this situation,
- Sometimes a deadline can be useful, so you can make the final push when close to a delivery,
- Put effort into encouraging others to contribute and build content to make it easier for contributors and users,
- Try to utilise pair programming on the tough problems (where possible).
These guidelines come from my perspective, and I'm a mostly solo maintainer who works on open source in my free time and don’t rely on it for money. Different guidelines probably make sense for different projects.
Open source can be slow sometimes and that's ok, you'll get more done gradually over time than you will if you just burnout immediately by working crazy hours.
Picking up an existing project
I didn't build react native storybook, I started maintaining the project in August 2020 and built on top of the work others did before me. In the past few years I've seen some really great contributions and I’ve connected with really great developers. However it has been largely a solo effort for much of that time.
The main drawback of joining an existing project is that you’ll spend a really long time trying to get to grips with all the details and likely you’ll never know the context behind implementation details.
When tackling an existing project it helps to focus on one problem at a time and start by fixing the bugs that you personally have experienced and making small improvements to parts of the code. Over time you’ll find yourself understanding the project better as a whole.
I also respond to every issue, discussion and discord message. The reason being is that there is a lot to learn from your users and if you really want to get to know a project you need to understand the problems it has. Debugging user issues and seeing different project set-ups really taught me a lot. I encourage anyone in a similar situation to consider really diving into issue reproductions from time to time.
Being a solo developer
As a solo developer it’s sometimes hard to know what direction to take in a project. You can ask the community but in smaller communities it can be hard to get enough feedback to get a proper consensus. Many people who download your package probably never opened the repo on Github or joined the discord and so reaching out for feedback can be hard.
As a solo developer I often have to be somewhat ruthless when it comes to optimising my time, especially as it often depends on limited free time. This can be frustrating because of course I want to fix every bug and add every feature, however it’s not feasible.
With limited conversations about the project's architecture and direction it can be hard to get a good feedback loop and make improvements in a way that would benefit the community the most.
I find it really helps to lay out a plan or roadmap, even if you aren’t totally sure about it. Then just make changes over time as you get through it. Make it public and link to it when people ask about the project, and get their opinion on it if you can.
Building a community
Storybook is one of those projects that comes with this great community and it's used by millions of people. React native storybook is small in comparison to the other storybook packages and even then it still amazes me how many people are downloading it every week.
That being said, the react native project doesn’t have the same level of active community members. Growing a community is hard to do and users don't equal contributors.
Community building is something that I really want to focus more on in the future and I think documentation and updated tutorials will likely be a focus for v6. It’s also one of the reasons why I’ve been writing blog posts as I want to improve my technical writing and at the same time answer common questions about the project.
Preparing a project for contributors
Here are a few tips I think could help if you’re looking for ways to improve the onboarding of contributors:
- Avoid huge PRs as it’s hard to help if the project is always about to get a huge rewrite,
- Organise tasks/issues in a way that it’s easy to see what’s important for the next release - Github has a projects feature that is nice for this,
- Readme and Contributing documentation,
- Have a place for open discussion such as Github discussions or a discord server - issues do great for most things, however it’s not as easily approachable to new people.
Closing thoughts
After reading about all these difficulties you might come away thinking that it all sounds a bit much, however I don’t want that to be the takeaway here. The challenges here are what forced me to grow as a professional and as a person.
Building a community is one of those things that makes you reconsider how you communicate, it drives you to consider how to respond to feedback and how to encourage others.
Struggling with burnout taught me a lot about work-life balance and working as a solo developer taught me about organising my work and the importance of reaching out for help.
A special thanks to the storybook community and to those who’ve helped me along the way.
If you want to get in touch you can find me on twitter: https://twitter.com/Danny_H_W
You can find my work on Github here: https://github.com/dannyhw
citations
[1] Maslach C, Leiter MP. Understanding the burnout experience: recent research and its implications for psychiatry. World Psychiatry. 2016 Jun;15(2):103-11. doi: 10.1002/wps.20311. PMID: 27265691; PMCID: PMC4911781.
