I have been paid to write code for the greater part of about 5 or 6 years, in various forms. Only about 3 of those years have been in industry since graduating from school. In school, I worked on various projects for professors and clubs. At work, most of my projects have been centered around creating line of business or internal infrastructure applications.

I haven't ever really sat down to write code with the intention of someone else leveraging it outside of my team or organization. Last year I wrote my first npm package and even that was only meant to reduce overhead for my team.

After reading Working in Public by Nadia Eghbal, I asked myself: "Why don't I contribute to open source software (OSS)?"

I've thought about it before, and I have tried to a certain extent. If I do want to branch out more, and give back to the community there are a few things I need to confront first. Hopefully, if you're reading this and you've had similar struggles; this post can guide us both to a better place.

Reasons why

1. I don't know how to start contributing

I've had a few false starts contributing to OSS by finding a new-to-me project, skimming through their issues and trying to find an easy PR to write. Usually what happens is I'll find a reasonable task, read through it, and then start trying to find the code relevant to the task at hand.  Then, nothing.

Not all projects are structured the same way. Since I'm used to working with application code, it's harder for me to figure out where to even get started with a framework or library.

Usually this "effort" lasts about 2-hours maximum and then I get distracted or just give up. I don't overly enjoy being frustrated, much less when I'm not getting paid for it.

2. I don't want annoy project maintainers

When I start on a new-to-me project at work, there's usually quite a bit of knowledge transfer and hands on guidance until I'm able to get going on my own. In the workplace, this is pretty common and teams carve out capacity for onboarding new developers.

In the wild west of OSS, there's no expectation that a maintainer takes the time to manually bring everyone who wishes to contribute up to speed. Maintainers don't have that kind of time, and there's no guarantee that these contributors will stick around to even see a return on those investments.

When I look through issues and PRs in GitHub, I always assume everyone kinds of knows each other or has a lot more context than I do. In reality I know that there probably are pockets of core folks who know each other, but many people are just strangers passing by.

On top of all of that, each project also usually has some kind of norms and guidelines about how to contribute. It's a lot to keep track of when you're just getting started, which is why I feel like the first PR is the hardest to get through. I've got pretty thick skin, but I know that I'd feel really silly sending out a PR that gets tons of basic feedback; or doesn't even get reviewed because it doesn't follow the rules.

3. I don't have time to dive into new projects  

As I mentioned before, my approach thus far has been to just try to drop everything and dive deep into a new open source project. I find something that seems neat and has a bunch of issues to look through.

Trying to figure out the existing code, takes a lot of time. It's very silly for me to think that just by sitting down and holding my fingers near the screen that I might absorb and grok it.

I probably wouldn't mind writing a little bit of code here and there in my off time, but I'm much less likely to try and read documentation or do the hard work that is required to get familiar with a code base. If I'm contributing in my off time, I only want to do the fun stuff!

How I can get started

I do not think that you have to contribute to OSS to be a good developer. However, it's important to me because I really value community contributions. I try to stay active in meeting new people, and learning new things and OSS seems like a place where I can achieve both of those things.

I can start observing a project I already use

One of the flaws to my original approach was always trying to find some project I'd never heard of before. If I'd never heard of it, I'd certainly never consumed it as a user. If I really want to break through to making my first community contribution, I think I should pick a project I already use on a regular basis.

A great piece of advice I got about "junior" versus "senior" engineers was that juniors understand how to use the tools (libraries) and seniors understand how the tools work. Obviously, this is pretty reductive; but it did give me an idea.

I could take my existing knowledge of the things I consume at work, and jump to the other side and look at the source code that makes up those packages. There would be a lot less head scratching if I would focus on a project I already have some context on.

I can start by making non-code contributions

An important thing I learned reading Working in Public was that not all contributions are code related; and most people don't get started by opening a PR immediately. I could read through contribution guidelines, issues, and PRs and try to help maintainers triage issues instead of actively writing code.

Documentation is also an incredibly valuable part of a project, since it's hard to get new users without it. Since I'm already working on brushing up my technical communication skills (a la this blog) I could look for areas in an OSS project that need more documentation.

When we're not under such strict COVID-19 restrictions, I want to start giving talks again and I could very easily convert these documentation adventures into talks. Double-whammy!

I can tie this into my capacity at work

As I mentioned before, I am not likely to do the hard work required to fully embed myself within an OSS project when I could be walking my dog or hanging out with my friends; at least until my friend start contributing to OSS projects. ;)

However, Microsoft has been making more investments into OSS and my manager even encourages us to find opportunities to contribute. I could carve out some capacity at work and use part of my professional development time to grow and learn. There are opportunities to bring these learnings back to my team and encourage others to contribute as well; which would help others on my team grow and learn.

Conclusion

It turns out, I don't have very good reasons not to contribute. The barriers in my way are mostly self-imposed or can be solved with a little bit of gumption. Whenever I get around to finding my first victim, I plan on documenting my journey and will hopefully give a talk on it when things get better outside.