So you don’t have a slew of open source contributions under your belt? Bad run-in with open source once that left a bad taste in your mouth? Feeling some imposter syndrome over your lack of open source contributions?

You’re not a bad programmer because you’ve struggled with contributing to open source. It’s difficult, and it requires knowledge and skill sets completely different from, and in addition to, programming.

But let’s say you want to do it anyway. There are tons of excellent reasons to contribute to open source:

• You love a particular project and you want to help
• You admire a particular maintainer and you’d like to work with them
• You feel ennui in your job and you’re looking to save the world in your off hours
• You like getting yelled at by entitled parasites on the internet (just kidding)

There is a bad standalone reason to contribute to open source: leveling up your programming skills.

Contributing to open source is by far not the easiest way to level up your programming skills, so if that’s all you’re looking to get out of it, I don’t recommend it. That’s like trying to improve your baseball by going out for your local minor league team. First of all, making it onto a minor league team requires insider knowledge of the baseball business that has nothing to do with getting better at baseball. Then if you make it onto the team, the learning curve will be vertical, you’ll feel a lot of pressure, and you’ll be extremely likely to overextend yourself—which is not great for your long-term success at baseball. A better solution would be to find a low-stakes environment where you can improve at your own pace, maybe with regular feedback from some not-superstar-but-decidedly-better-than-you players in your community. Same with programming. If you want to improve your skills, you’ll get a lot farther with a lot less heartache by incrementally working on your own project and reaching out to some respected programmers you know to ask for some one-on-one feedback on your work.

Let’s just say that leveling up your programming skills isn’t your only reason, and with God as your witness, you want to contribute to open source. Awesome! The skillset needed for open source contribution is part communication, part psychology, and part straight up patience. Here are some lessons I’ve learned*:

1. Over-communicate (and especially make sure maintainers know when you are working and when you are not). People need to know when they can reach you and when your work will be ready. If you’re remote, the maintainers cannot see you. When people can’t see you, they get antsy about not knowing where you are. Over-communicate what you are doing and when you are and are not available. It is totally OK to set boundaries on your time. In fact, it’s healthy. Do make sure that, if you are not available, that your temporary absence is not a surprise to the maintainers.
2. Ask before you do anything. If I have a feature in mind, I’ll ask the maintainers if they’d like it implemented before I embark. There might be important context around that feature, or previous attempts at that feature, that I need to have in order to do useful work. If I don’t have time for a feature right now, I’ll ask the maintainers if they would like me to comb through the issues and fix bugs/answer questions. Maintainers never have time for this, so surely they’ll want you to do it—right? Not necessarily: as I mentioned, maintainers never have time for this. Some projects elect to manage this by publicly stating that they don’t respond to issues and leaving it at that. Remember, you are new to this team. You need to learn the team’s established agreements in order to be a helpful team member.
3. Only take on a feature, especially a time-sensitive one, when you have a large chunk of uninterrupted time to offer. I will take on a project if I have a whole weekend to spare, or at least three completely clear evenings in a row. I do this because I do not want to feel like open-source is encroaching on my other life commitments. It’s easy to accidentally overcommit on an open source project because the maintainers always need more help than you alone can provide. You need boundaries and you need time for yourself to sustain your contribution efforts.
4. Ask before you do anything. I put this twice because it’s doubly important. In this case, specifically, ask about code conventions before you write code. That way, you’re not surprised when you turn in a draft that you’re proud of, only to learn that this team is strictly dependency-free or strictly PEP 8 or strictly some other thing you didn’t do. You won’t want to redo all your work because you blew by this step. Trust me.
5. Do things their way for the first 2 or 3 features. Maybe you think the strictly dependency-free or strictly PEP 8 thing is silly. Do it anyway for a little while. Remember, you’re new to this team. Open source maintainers get a lot unsolicited advice from fly-by people who don’t really help. You can differentiate yourself from the fly-bys when you add value to the project, and maintainers will become more receptive to your ideas. You’ll also have gained some credibility because you’ve already tried things their way. And who knows? Maybe you’ll learn something by trying on a different perspective.
6. Patience, patience, patience. Your first few pull requests will probably involve a lot more back and forth than you expect. Open source maintainer reviews far outstrip the intensity and nit-pickiness of coworker reviews on paid projects, in my experience. Be patient, make the changes they ask for, and resubmit. 6 times, 8 times, whatever it takes. In the grand scheme of things, you won’t even remember the extra week or so that it took to get your first contribution approved. And once the team knows you better, they’ll get a little less helicopter-y. Maybe.
7. Know when to call it quits. It’s frustrating but reasonable for your initial open source pull requests to undergo more scrutiny than you expect. Sometimes, though, you can tell that working with a team just isn’t working for you.Maybe the maintainers cannot be bothered to answer your questions, even though you’ve already made a significant effort to the project. Or maybe something else is happening on the project that just feels icky to you.

   I worked on a project where I completed a feature, but a maintainer and I disagreed about the solution (I used a dependency and the project tried to go without dependencies). I agreed to redo it, but I wasn’t thrilled about it, so I put the project aside for a few days to collect my thoughts (and I should have communicated better that I was doing that). When I came back, a maintainer had completely rewritten the feature from scratch. He used all of my big ideas about how to design the code, omitted the dependency I had used, and introduced a different dependency on a different part of the code where I had not used a dependency. When I confronted him about rewriting my solution, he explained that he ‘agonized over whether to do it’ but ultimately decided that he wanted to start from scratch so my code did not ‘cloud [his] judgment about possible alternative solutions.’ I was devastated, but I recognized that I had made some mistakes by failing to communicate my absence and failing to ask about code conventions. So I decided to try again on another feature. This time I did ask those questions and communicate. I got the code written and asked for some assistance getting accustomed to the deployment architecture. Instead of doing that, the maintainer copied my code and deployed it himself. After that second occasion (plus some other subpar experiences with other project contributors), I decided to cut my losses and stop contributing to that project. My stress levels dropped precipitously.

In Conclusion

Lacking open source contributions doesn’t make you a bad programmer; open source requires its own knowledge base and skill set. That said, there are many good reasons to contribute to open source, even though it is not the most efficient way to level up your programming skills. To contribute effectively, you’ll need to employ communication skills, a little bit of psychology, and a lot of patience. Most importantly, over-communicate what you’re doing on the project, and try to picture yourself in the maintainers’ place before you scoff at their scrutiny. It’s also helpful to know your limits and know when to call it quits.

*Most of the projects I’ve worked on outside my day job were what I call open-ish source: charity projects whose repositories are nonetheless private. That’s why you don’t see a bunch of pull requests on my Github as evidence of my experience with contributing: they’re private. There are many reasons for an org to keep repos private—not the least of which is that, when you have a distributed team working in an asynchronous fashion on something complicated, people are going to push API keys by accident often enough that you cannot afford full-scale damage control every time it happens.

If you liked this post, you might also like:

My Favorites Collection from Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

A (Very) Brief History of the Laptop Computer

This Breakdown of Michael Feathers’ Talk on Edge-Free Programming