Hacktoberfest is happening and many folks have been blogging about how it’s not a fair representation of how to get involved in open-source, it’s known to be spammy, and arguably bad for open-source itself. So, I wanted to write something how to get involved in open-source without chasing some stupid t-shirt based on a number of commits. (EDIT: Hacktoberfest realized that no one loved the spam PRs that happened to start the month off, and added some guardrails to improve the experience. Good for them).
Furthermore, as a software engineer at 47 Degrees, I’m ostensibly a member of the open-source community, since 47 Degrees spends a lot of time and resources on maintaining a few hundred libraries in Scala, Haskell, Kotlin, and Swift. However, unlike other folks at the company who were involved in open-source before they joined, I was never involved in a significant open-source project before joining. I’d used GitHub for my own side projects or as a place to publicly share my learnings, but I’d never really gotten involved in a project that involved collaboration outside of myself. So, when I accepted my offer from 47, one of the first things that I wanted to do was to make my first significant open-source contribution.
However, one of the key things I wanted to do with respect to my open-source contribution was to do it from the perspective of a non-employee as much as possible to simulate the experience of what approaching a popular open-source project as an outsider might feel like. I think this is an important perspective to take when thinking about open-source contributions – tons of really good open-source is done by teams that are sponsored by companies (e.g. React, TypeScript, and Kubernetes, to name a few), and while that’s great for the state of software overall, it can be a barrier to entry for first-time contributors because they likely don’t have the have the same level of access to the library maintainers as employees of the companies that maintain these libraries do (they’re not on company slack, can’t just roll over to their desk, etc). With that in mind, I decided that my first open-source contribution on one of 47Deg’s projects would happen before I got hired, as a community member, with access to the same tools and context as any other engineer would have.
Fortunately, since open-source is such a community-driven effort, there is a relatively mature ecosystem of tools that help bridge the gap between wannabe contributors and maintainers. In my opinion, the most important thing you need as a new open-source contributor is a way to communicate with the more knowledgeable folks in the ecosystem in an open way, so that you can get as many helpful eyes on your question as possible. Emailing the contributor can be a good start, but emails are not transparent, nor are they linkable, and if all collaboration efforts happened over email you’d likely have to repeat yourself much more. Here’s a brief list of the tools I used to facilitate communication between myself and the library maintainers:
There are other tools out there, of course, but these were the only ones that I found both (a) essential and (b) transparent enough to simplify the knowledge-sharing process.
That said, despite having implemented my open-source contributions from the perspective of a community member, I still had one big advantage in my experience that differentiated me from many other folks looking to get involved in open-source: direction. An engineer at 47 Degrees, during a conversation that we had prior to me receiving my offer, mentioned that were several open issues in the project that needed some attention from the community, and even showed me where I could look in the code base to address these issues. For me, this was a great help in overcoming the barrier to entry for open-source, since before I even touched the codebase I had a concrete task to work on and some idea of how the implementation could be done.
I recognize that most people won’t have this experience of having their first open-source contribution handed to them like mine was, and so before I wrap up this post I want to share a few ideas that I’ve come across that I think are helpful for folks who seek that initial motivation and direction to get involved in open-source
I had a lot of fun working on my first open-source contributions, and I look forward to maintaining the libraries I’ve become involved with for hopefully some time. That said, my last warning I want to give is that in addition to all the other things you need to know to get involved in open-source, the biggest resource you need to be willing to dedicate is time. Open-source isn’t something that you can occasionally drop in and out of and expect to feel useful and fulfilled. But, if you have the time, are willing to put in the effort, and are open to talking to strangers about their work, open-source can be incredibly rewarding. As with most intimidating tasks, the feeling of achievement afterwards makes any struggle with the initial process worth it.