First Time Contributor: Making an Impact in an Open Source Project

In consulting, lulls between assignments are an excellent time to investigate a new technology or language. Sometimes, that effort leads to being able to contribute fixes or new features to a software community. Doing so creates the opportunity to expand our skill-sets and deepen our understanding in new areas of software development. I recently had just such an opportunity.

As we anticipated some of the needs we could expect for an upcoming assignment, we looked into an open source JavaScript project called angular-schema-form (http://schemaform.io), which is built using the AngularJS framework. It showed some promise for our use case needs. However, as we were evaluating it, we noticed that there was a pretty significant drawback. In some circumstances, the information displayed on the web page would become out of sync with the model representation created and maintained by the project. This could cause data integrity problems if submitted to the server without correction. We checked the project’s GitHub page and found that the issue had been reported several months ago. The project developers had agreed that it would be nice to have a fix, and welcomed anyone who wanted to submit a code contribution with a solution. With an open invitation and a problem to solve, I decided to invest some time and energy to help improve the project.

This was going to be my first public contribution to a JavaScript project, which is not the language platform that I am most experienced with. However, identifying a specific issue to tackle gave me a perfect opportunity to learn more about the development environment and ecosystem that now exists in that space. Tools like Bower for dependency management and the Gulp build system were already in place, and I needed to understand how to use them in order to work with the project. I also spent some time getting familiar with the documentation for AngularJS as I built out my understanding of how the framework is structured. This effort was important, giving me the information necessary to move into the project that I wanted to help improve.

Armed with that information, I turned to the project itself. I started by reviewing the project documentation and code base to ensure that my contributions would fit well within the whole. This is a valuable skill to have, regardless of whether the project is open or closed, internal or client-driven. Discussions with other users in the GitHub discussion threads provided additional insight into what other people hoped to see in the new feature. These points gave me a set of goals that could be used as acceptance criteria. At this point, writing the code for the new feature was fairly straightforward. Once I was confident that my solution was ready to share, it was time to submit the code to the project.

I wrote up an addition to the documentation covering the new feature and submitted a pull request to review and include my code. The review process was an excellent learning opportunity, as the primary developers for the project were able to point out a couple of improvements to my coding style and uncovered a sneaky bug that I had introduced. It was very clear that they appreciated the time investment that my contribution represented, and they wanted to make sure that the result was high quality code. We went back and forth several times with new suggestions and updated code commits. Within about a week we had improved my code submission significantly, adding new functionality and reducing complexity. The back-and-forth communication was key to this process; I learned nearly as much from the review as I did from writing the solution in the first place.

This entire process played out over the course of about two weeks. In that time, I learned new development tools and processes, improved my fluency with JavaScript and AngularJS, and solved a specific problem in an open source project. We reaped further benefit when we were able to use the project on a client assignment, improving our ability to delivery a quality solution because of the improvement to the underlying tools. Other schema-form users will have the chance to replace custom workarounds with the officially supported feature within the project. In the end, I gained experience, the open source project gained a desirable feature, and the client gained a better solution. If you are thinking about contributing to a project, or if you see an issue that you think you may be able to solve, I want to encourage you to go for it. It can be a rewarding process.