Lately I’ve been doing a lot of introspection. These blog posts are less about the technical side of what I do, and more about the human side.
One question I get asked often is “why do you contribute to open source?”. Open source to me is a full time hobby — I will usually spend at least an hour each day on open source activities. It’s not unusual for me to work on something after work until the early hours of the morning.
Let’s take a rough look at the different parts of open source contributions I do.
Learning from others
An important part of a healthy open source project is the community. I’ve written previously about how I try to help the community via support on Slack, but not about how I justify doing that in my day. The truth is that I just enjoy helping people learn things. I want to understand things other developers do, and I want them to understand things that I know. Through helping people, I become more familiar with different ways of thinking or approaching problems. I’ve become familiar with many different ways of achieving the same goal just by talking with people.
In my day job, this helps me understand my teammates and offer alternative solutions or productive counter-points. If I hadn’t talked to a person about alternative functional CSS approaches, then I wouldn’t have the same confidence in the one we end up using. You can get this experience by talking to people you work with, too. But there’s over 10,000 people in the Elm community online too, and they are working on very different projects to you.
Leveraging people power
The more people who know how to achieve something, the less work you have to do. For example, guiding someone on how to make a particular package can save you a lot of time rather than making it all yourself.
At a previous company, I worked closely with several people who were active in the open source community. Not everyone was, but a large amount of people were. One thing I’m proud of doing is encouraging people to contribute to my projects or to create their own. I paired with a developer that had never published anything open source before beyond small projects. They were nervous — publishing your first package has a sense of weight that you forget about later on. Every package you push has the potential to become a chore or a blocker. I believe it’s important to reassure new contributors that they won’t have to sacrifice any time that they don’t want to. Sitting down and talking with them about how you work on a particular package can go a long way to do that.
Encouraging involvement of new people is not just a way to grow the number of overall packages, but also increase the quality of existing packages. Some developers may not feel comfortable opening issues on libraries — but as an open source maintainer, issues are the way that I know which libraries are being used and need improvement.
Some users may even become regular contributors to open source repos that you own. In my particular case, stoeffel and rtfeldman are two such people that I am happy to add to any project I make. Contributors are your teammates and colleagues in the world of open source. Finding ones you gel well with can reduce the amount of stress you feel from a project. With these developers, you know that you don’t need to set aside a large section of time to vet pull requests.
What about overworking?
Sometimes things are tough. You have a ton of day job work to do, and people are tugging at you on Github for your open source work. You may be on holiday, or feeling sick. Replying to notifications and emails is an addiction. With a day job, the boundary is clear — you have a contract which states the hours you work. Not so with open source. That’s all about self control and time management.
One tip I received from an old colleuge was to keep track of the hours you did. It’s easy to spend all night fixing something, only to feel guilty the next day for not replying to some other issues. Keeping a personal note of what you did and how long it took can help you justify to yourself that it’s okay to take a break now. It might sound strange, but it really works. These days I make checklists using org-mode, and tick things off as I go. They’re personal notes to myself, so the detail and the specification of what I did is entirely up to whatever I feel like writing.
In the Elm Slack, I will often get pinged for edge cases or things others aren’t familiar with. It can take 10–15 minutes to reply to these pings. My general goal these days is to answer to the point where someone else can take over. If it’s something I haven’t seen before, then I will usually keep replying myself. I want to know what they know, and relate to their experiences. If someone is active in our community, I probably know what they work on and things they made. That helps me when I get stuck, because I know who to reach out to.
A more casual side of open source is meetups. I enjoy going to Elm meetups and seeing what people are talking about. If someone gives a talk, let them know what you enjoyed about it. Encourage people to talk about things. You’d be surprised what you can learn about a topic even if you’re the one who wrote the thing they’re talking about. The confidence boost you can give someone by thanking them for their talk or just reaching out and saying “hey, I’d love to hear you talk about X” is a great way to make someone’s week. The same applies to online communication. Reach out to people who are doing good work, and let them know they’re doing good things. You could do something as simple as replying with emoji to their messages. My personal favorite is :tada:. If someone is helping you become a better programmer or person, tell them that!
Finally, one thing I’d like to touch on is how important my open source work has been in my day job. Processes, communication and techniques that I’ve picked up from the open source world help me be a better programmer. What should an issue look like? I work with issues made or consumed by a wide range of people in the open source community, and it’s helped me learn how to effectively write a helpful issue. How should I disagree with someone? Communicating a different opinion online with a wide range of people has helped me understand how to write in a way that others find agreeable. How does good documentation read? I learned to write about a project or repo in such a way that anyone could get started with it, and that’s a great tool for working in an async team. How do I debug a library that I’ve never used before? In my open source work, I use and evaluate far more libraries than I do in production.
tl;dr
So tl;dr: open source contributions don’t need to become your life to be useful. Opening an issue or answering a question is vitally important for the growth of a community. If you find yourself overworking on open source stuff, keep track of the things you’re doing and justify “time away” to yourself. Enabling others to work on your projects or creating projects of their own is a great way to reduce the stress on you. Open source has taught me a range of skills that I find useful day-to-day, and if you haven’t taken part before, give it a try!
