.jpg)
've been working on open source projects for the past few years, most of that time spent working on Storybook for React Native.
I'd like to share a bit about my experience, why I continue with it and some of the things I learnt along the way.
What is open source software?
For those of you that aren't familiar with open source, I'll try to explain it quickly here. There may be many different definitions but I'll give my own, based on my experience. I'm talking about software that is free and collaboratively authored in public, and this means it's:
- Free to copy;
- Free to read;
- Free to modify;
- Free to contribute.
It's free as in freedom, and free as in without direct monetary cost. There are of course exceptions, but I think this covers most cases.
Why should we care about OSS?
Much of the software and technology we use is often almost entirely built up from open source libraries. I think it’s fair to say that we wouldn't have the technology we have today without open source.
Open source relies heavily on community and those who volunteer their time. Not everyone has to contribute, but we all benefit from those who do.
What is Storybook?
Most of my open source experience has been through the lens of Storybook and its community, so I think it will be useful to briefly cover that.
Storybook is a toolbox for creating UI components. It provides a way to develop your UI components in a sandbox environment. Storybook also offers features for testing and documentation and a growing list of use cases.
To me, one of the most interesting things about Storybook is how extensible it is. Additional functionality is provided via add-ons and many of those are authored by the community.
Due to how extensible Storybook is, it supports a lot of frameworks, both officially and unofficially (officially as in under https://storybook.js.org/).
If you’re working with UI you might ask yourself: “Does Storybook work with my software stack?“. Often, the answer is yes. This was the case for me when I was working with React Native and I came across @storybook/react-native.
How I got started in open source
Some background will be useful to give context around what made me start contributing.
Back in 2020 I was working on a new React Native project. We had a web-app where we were using Storybook for our design system.
We had a goal to reuse code and ideas from the web app for our mobile app. When we started working on the design system for the React Native app, it was decided we should investigate Storybook for React Native.
It worked well for us for a few months. However, around that time a new version of React Native was released and we started running into issues.
React Native Storybook
At this time, the React Native Storybook project was in flux and it was somewhat difficult to find information about the issues we were having. There also didn't seem to be any active maintainer.
I started thinking about how to solve this problem myself, I was convinced that there had to be a simple way to solve this.
Since the project was inactive I first thought about creating my own solution, but for many reasons that just wasn't viable.
I thought: "It's simple, I can do it in a weekend"... Famous last words.
At this point I was not really sure about what to do, I had exhausted a lot of my initial ideas and was ready to give up on finding a solution. As a last resort I figured I should at least try to reach out to the maintainers of Storybook.
In hindsight, my first move should have been to make an issue or reach out to others in the community. However, I wasn't really aware of how open source worked at that time.
What I found is that the maintainers were happy to answer my questions and were ready to take my offer to help seriously.
I didn't really expect that I would become a maintainer. What I learnt, though, is that asking questions and getting involved is all it takes to be a contributor and everything else follows from there with time.
Ask for help
It's easy to get caught up in self doubt or pride and write off getting help as unnecessary or not worth it. Maybe you feel your problem isn't big enough. However, I think that given you are considerate of other people's time and show appreciation there's no harm in asking for help.
I bring this up because I think that often this is the gateway into getting involved which projects that you're interested in. You can start by asking questions and giving feedback and transition that into small PRs and so on.
This can be on a GitHub issues and discussions, discord servers or a community slack. This will depend on the project and many projects will advertise their own community space in the readme.
I think there are a few key guidelines to follow when reaching out, heres some that I've adopted based on my experience:
- Be polite;
- Show appreciation;
- Don't ask for something with nothing in return (i.e Offer to help);
- No-one owes you anything.
What I mean by no-one owes you anything is that in the open source community we're mostly here in our free time and there's no reason that a maintainer needs to help you. However, they often do so because they care about the project.
Take a moment to think about how your message sounds, read it out loud and, if it doesn’t sound friendly, try rewording it. It’s important to remember that there is a real person behind the screen and being friendly goes a long way to getting the response you’re looking for.
You can contribute too
This might seem obvious to some, but I think sometimes there is an assumption that you need to be this amazing 10x super mega developer to contribute to projects you care about. However I think that isn't true, and most projects really want your help.
Not to mention that you can always build your own projects and grow communities around them - this is something that's more difficult but definitely rewarding.
Personally I often felt out of my depth as a maintainer but I was lucky enough to have the guidance of multiple people, especially Norbert and Michael on the Storybook core team.
Imposter syndrome is real and hard to avoid; however, I think it's important to realise that what makes you a contributor is just getting involved and not much else. Just by showing up and doing your bit over time you can achieve a lot.
Why contribute
There are a lot of reasons I think it's worth it to contribute, and since some of them are, in my opinion, easy to understand, I will not cover them in detail.
Here's a list of some of the important ones:
- It's fun to work on something with no obligations;
- You can give back to the community and projects you like;
- Fix your own problems;
- It feels good to help others;
- Self promotion;
- You'll learn a lot.
I also think it’s fair to say that OSS is not for everyone and you shouldn't feel pressured into doing extra work. If you are interested in a project or you want to build something cool that you can't do during work hours, then I think OSS is a great place to scratch that itch.
How to contribute
Contributing to a project can come in many forms, and like I’ve mentioned already this can be in the form of raising issues or giving feedback. Not only are these things useful, they are also a good way to work toward making bigger contributions.
When looking to contribute to a new project, look out for issues that are labelled as beginner-friendly or that seem relatively easy. Your first contribution likely won’t be a game changer, and probably shouldn’t be. It will take time to get understanding of a new project and understand the context around the architecture and design decisions.
When diving in to make your first PR, consider the following:
- Start small;
- Comment on an issue to explain your interest and ask if it can be assigned to you;
- If you don’t know where to start try reaching out to ask what issue would be good for a newcomer;
- Ask questions;
- Consider using community channels like discord if it makes sense to do so;
- Read the contributing guide;
- If you have trouble getting started, improving the documentation might be a good first contribution!
Make sure you let the maintainers know you’re interested - they might be able to offer assistance, and it always helps to know who’s working on what issue so that work isn’t duplicated.
Don’t be disheartened if you don’t get a response right away - it's easy for notifications to get lost and sometimes people are busy.
The best way to get started is to contribute to projects that you already use often. This way you’ll already have a large part of the context that's needed to get started. Alternatively, start your own project and share something cool with the world.
Closing thoughts
Open source projects are a great example of what can be achieved in collaboration with others, and it feels great to be a part of that process. I hope I’ve given enough reasons here to persuade you to give it a try - and if not, that’s ok too!
Thanks for taking the time to read this far - this post is the first part of a series I want to write about open source. The next post will be about the challenges of open source, including my experience with burnout and how I avoid it now. Keep an eye out for that next post if you’re interested, or follow me on twitter and I’ll share it when it's out.
You can find me on twitter here https://twitter.com/Danny_H_W.
You can find my work on Github here https://github.com/dannyhw.
