My first open source contribution

Why you should give it a try too

Fight the imposter syndrome

I know contributing to open source projects is a daily task for many developers but I am sure a lot more still do not dare to take that step. They do not think that participating to an open source project is not for them. Most of the time this situation comes from the fact that they do not feel confident enough to participate. A bit of the impostor syndrome. It was my case…

…until now. I am lucky enough to be part of an organisation (Worldline Group, formerly Ingenico) that encourage participating to open source and this time I took my chance on one project.

In this article I will walk you through the internal process I faced when I decided to participate to an open source project. You will discover the different steps I took, both anticipated and non-anticipated ones.

Find a project that makes sense to you

In my case, I am more comfortable with JavaScript and NodeJS projects.

In my company, we’ve put in place multiple React projects and, of course, the NodeJS transpiling pipeline that comes with it. For our projects to be safe, we decided to scan their dependencies for security vulnerabilities. This process has been put in place as part of our continuous integration.

Logically, we first used “npm audit” as it is the built-in solution. But we started to wonder if we could find a better tool. Yes, “npm audit” has some limitations.

First, the same vulnerability is being reported multiple times. Indeed, if multiple packages depend on the same infected package, the vulnerability will be reported for each package that imports it. This complicates finding the root cause of a reported issue.

In addition, the npm’s builtin audit tool is not flexible enough for our needs, we would like to have the possibility to flag a vulnerability as known and still keep our builds going. This may happen when, after analysis, we decide that a particular vulnerability does not affect us or when we decide to wait for the dependency author to fix their code.

After some research we decided to give auditjs a try. This project is backed by Sonatype, the company behind the Nexus repository, and uses a manually curated vulnerabilities index: OSS.

This solution also provides a way to whitelist known vulnerabilities. This allows us to control whether a particular issue should be blocking our build or not.

The tool output is also more readable and easier to understand.

Start with something small

After trying and successfully integrating this tool in one of our projects, we came across a problem when using this solution into our CI server: the tool does not accept http proxy configuration.

In our organisation, CI servers do not have direct access to the internet and must go through a proxy server where connections are closely monitored and traffic is allowed based on a list of safe websites.

I looked at the code and found out that the tool was using node-fetch to perform network connections. The solution was thus to use an npm package called “https-proxy-agent”. This library allows creating an http agent to pass to node-fetch at the time of the connection.

Now it was time to integrate this solution to the source code of auditjs.

How to contribute

I work daily with git at work, cloning repositories, creating branches, committing code, merging, rebasing, etc. but I never did it for an open source project.

I On GitHub, the process is a bit different. While you can clone someone else’s repository on your machine, you cannot push a branch there as you do not have the rights. You first have to fork the project.

As I am doing this as part of my work at Ingenico, I forked it into the GitHub organisation created by my company.

Once you are part of a GitHub organisation (the organisation owner should invite you), you are asked where you want to fork the project (in your own repos or in your organisation’s repos)

I forked it in my organisation’s repositories and cloned it locally. At that point, you can make your changes, create a branch, commit your code as you would do it normally.

Once done, you can push your branch to your repository. GitHub will detect you pushed a branch to a project that you forked and will propose you to create a pull request on the original project (either from the link provided when pushing the branch or from the repository’s page on your GitHub account).

You land then on a page to create a pull request for merging your code to the original repository. This is where you’ll find the repository’s particular set of rules.

In the case of auditjs, they reminded to add a note in the documentation to describe the new feature, which I forgot to do at first.

Once you conform to the repository’s requirements, you can give a comment explaining the purpose of your commit and submit it.

Interaction with the project’s maintainers

Once you created your pull request, you have to wait for a feedback from the maintainers of the repository. In my case I was lucky: I got an answer the next day.

From there a discussion takes place with them, small comments are made. I do the requested changes and in about 2 days of back and forth (we are not in the same timezone), the pull request is accepted and merged by them.

I must say that the interaction with the maintainers have been very kind and friendly. At the end of the day, they are just other developers that appreciate help as much as we do.

The next day, a new release has been issued with my changes and I am now able to use this tool in our CI pipeline.

My takeaways from this

Contributing to an open source project is really not hard. Indeed this is just another development task on a project started by someone else. How different can it be from working on a project created by a colleague. Yes, you have to read and understand the code. Yes, you have to adapt to the architecture/code structure of the particular project. But you should’ve done it anyway in your own company. And if your input may be valuable to the project, and most probably it will, jump right in and contribute.

The community is generally friendly and benevolent. At the end of the day, the maintainers are other developers just like you. They invested their time in doing something they believed in. They will be more than happy to get some help.

If you never tried contributing, give it a try and you will be proud of yourself and you will meet other developers. And, who knows, you may meet some of them in a conference some day.