The path to open source contributions

How can you give back to the open source community through sponsorship?

In 2017, Black Duck, an open source security platform, conducted a survey and found that 90% of all IT workloads include open source software. In the most recent Octoverse report, 94% of the public JavaScript repositories are powered by open source packages.

Open source can be extremely valuable to your career – and an understanding of how to participate can be the difference in leveling up as an engineer. But unlike books and online courses, there is no clear path for folks to contribute upstream and grow expertise in open source contributions.

Whether you are beginning your career or have been at it for years, open source is the path for modern developers shipping code. It is likely you have heard of and are using open source, but very few of us are actually contributing back to it, and the ones that are make up a smaller population. To better understand this, I am going to draw from a personal story.

My path into open source

My path into open source was not unique. I had the benefit of contributing to projects early in my career by chance and interest. I’ve benefited from open source for as long as I’ve been doing web development as a career. My first introduction to open source was through a Node.js project. At the time, in 2014, my first competent web framework learned was Ruby on Rails, which gave me confidence in jQuery but no knowledge in JavaScript at the time.

Together with a group of friends, I embarked on shipping a project that would force me out of the Rails paradigm and required access to WebSockets. (This was a year before the ActionCable WebSocket library was shipped to Rails.) The project we were building was a Slack group for people of color in tech. Slack was brand new at the time and we were looking to build a powerhouse of folks we could connect with online.

I was given the task to lead all engineering efforts and jumped into building a bot to auto-invite people to the group. Today, this is a solved problem, and there are countless third-party solutions for inviting folks to Slack groups, but at this time, the concept was new.

I was a newly-hired junior programmer and at that point, I had never built any bots or automation tools before. Through a Friday evening of Google searching, I discovered a GitHub repository with a README that claimed to be the solution. I cloned the repo and followed the listed commands, but could not get it to work. I struggled for hours with no luck. As I mentioned earlier, my knowledge in programming came exclusively from Ruby on Rails, and this project was written in Node.js – a server-side language for JavaScript.

Marked with failure, I scoured the repo for clues and decided my last attempt to get this to work would be to reach out to the person that wrote it. I was not familiar with how GitHub Issues worked and so I reached out directly via email instead of actually opening up an issue or pull request. To my surprise, he answered.

He pointed me to the answer and even provided Stack Overflow links to help support me in learning the details behind the error messages – a skill I still use to this day. He was super helpful and it got to the point where we were even corresponding through the weekend.

Fast forward to today, I work at GitHub as an advocate trying to do the same thing for others and pay it forward. GitHub is a platform for all developers, and though we can’t expect all open source contributors to learn the way I did, I hope that others would be inspired to also pay it forward by answering that email. I approached every issue like it could be their first issue on GitHub. I truly believe that everybody writing code can be involved in open source and have access to valuable information that could advance their career.

The barrier to entry

‘It’s a cruel jest to say to a bootless man that he ought to lift himself by his own bootstraps.’ – Martin Luther King, Jr.

In open source, it is common for folks to encourage participation by simply saying, ‘Start contributing on a project you like, today.’ But unfortunately, it is not always that easy. Not every project has a maintainer willing to answer emails on the weekends. Some projects are organized by foundations, or sponsored by full-time engineers that only work weekdays. If a developer approaches a project without any context, they may start contributing to problems already solved or projects that are not taking contributions.

The majority of projects I encounter do not have a CONTRIBUTING.md or a guide to onboard a new contributor – they merely offer a list of commands to copy and paste and a message of good luck. Contributing guides need to include context about what to contribute to, and who to reach out to for help if we expect folks to succeed in open source.

There is an issue of unintentional gatekeeping in open source, by which I mean that I do not think maintainers are actively trying to make it hard to contribute to projects. It takes work to mentor and maintain, which is why I love that sponsorship is possible in open source. As a community, we have the opportunity to clear a path for folks by investing time, money, and wisdom.

The lack of knowledge-sharing is how gatekeeping begins; it is a systemic issue in how humans interact. If only the privileged have access to information, then only the privileged maintain the system. The systemic racism that we have in the U.S., for example, really comes down to lack of information.

So, how do we start fixing this issue of gatekeeping? How do we bring new people into the fold and help them?

Organizations like React Ladies are awesome, but we need to continue to bring more and more people into the fold. We can do this through accessible open source. For example, we can give junior developers more exposure to open source contributions to ensure that the pathway is always clear for them to participate.

Investing in open source

When you start a new job at any company, the first thing you do is get onboarded. You receive a laptop, install all the necessary libraries and programs to get your work done, and talk to your new colleagues about the project(s) you’ll be working on. In open source, this catered onboarding does not exist.

In order to grow a community, you need to take care of the community. We can’t wait for everybody else to do it. In 2020, I was looking to do just that and put a call-out on Twitter looking for Black engineers doing open source. I had 15 people respond and I decided to sponsor all of them on GitHub.

Today I am in a position of privilege and have context on how to leverage open source to better my career through contributions. My hope is that these 15 folks can receive my knowledge through my sponsorship, where I provide them with information and opportunity as well as financial support.

One example I have is Monica – a.k.a. M0nica on GitHub. Monica is one of the individuals I sponsor. As of today, she has 56 sponsors on GitHub – 56 individuals willing to pay it forward and give her access to their insight. Monica is already doing great work with open source tools and I love that she is being rewarded for that.

I’m invested in the future growth of Monica and I encourage everybody who is reading this to do the same for other developers. This is not about money, it’s about access to information. The idea of mentorship in open source needs to evolve into sponsorship. Providing a pathway to contributions will not only shepherd new developers, but it will also sustain open source as a tool for future developers.

Conclusion

Open source is extremely valuable to your career – and the understanding of it can be the difference in leveling up you and your team as engineers. Consider setting up contributors with success by providing the proper context and documentation for them to succeed. If you are looking for a place to start, consider checking out Monica’s Getting Started With Open Source workshop for resources.

So I end with this question, who are you investing in? Who are you sponsoring today?