With seemingly everything moving to an open-source, community driven model, it was surely time in my development career to go through an open-source contribution; to see what struggles I would need to overcome, how to best add value to a complex code base, and how to collaborate over code changes remotely with the project owners.
Coming from a primarily .NET world, I've only started working within the GitHub ecosystem in the last year. Because so much of this open-source community is founded on the git and GitHub platform, I found the overall experience helpful in learning more about this community-driven side of coding, and also enhancing my knowledge of Git workflow, including squashing commits and rebasing branches.
The project my group (I'm currently a student at the Turing School of Coding and Design) was given to dive into is called the Open Food Network. This is the flagship project of the Open Food Foundation; a non-profit established in 2012 to develop, accumulate and protect open source knowledge, code, applications and platforms for fair and sustainable food systems.
The Open Food Network was established in Australia, and brand themselves as a holarchy, made up of self-organised layers working to create new and better food systems around the world. Essentially, it's an online marketplace (think farmers market on the web) that enables coops, independent farmers, and food hubs to connect with individuals and local businesses to sell and distribute their goods.
The first step in this process was of course to fork and clone down the GitHub repo and see if we could get it running in a local development environment. For this, we relied heavily on the instructions provided in the README and accompnaing documentation the project owners provide to developers. For the most part, we found the instructions accurate, updated, and easy to follow. We did however run into some versioning issues around Rails, as the project required a specific version, to which we needed to configure rvm to set the correct version.
The project also required a local PostgreSQL database to be setup, which was one of the few technologies our group did have some experience with. After configuring the designated database user, the remainder of the database setup was a breeze, due to the handy rake files that were included to create and seed the database. While we didn't investigate many tables in the database, we did use a couple to test changes that we were making to the front end. These relationships were pretty straight foward due to the consistant naming conventions.
Once we had the project running successfully locally, it was time to start diving into the code base. With a Ruby on Rails paired with Angular JS setup, the file and directory sturcture was pretty massive, but strucutured in a way that wasn't impossible to understand. The biggest struggle we ran into with the codebase was not only Ruby and Angular, but also Coffee Script, a JavaScript-like language that none of the team members had any experience in working with.
As mentioned, this project's foundation was split between Rails and Angular JS. This limited the complexity of the contributions we were able to implement within the timeframe of our project. Knowing that changes to these areas of the codebase would involve an understanding of how these would affect other areas in the application, as well as writing meaningful tests against them. As also mentioned, Coffee Script was used over JavaScript or TypeScript and PostgreSQL was used as the database, with active record handling the model layer of the rails architecture.
Going into this project, knowing our group had limited knowledge in the major technologies used in the Open Food Network code base, we looked at other ways we could still come away with a successful first open-source contribution attempt. For this, we primarily targeted fixing minor css/html bugs, and also creating new issues for things we noticed that could use some fine tuning.
We were able to submit and get approved one pull request, which involved some back-and-forth dialog with the repository owners. It was welcoming to see the warm reception received from the project owners for working with first-time contributors. They were very helpful in helping us understand where our code changes may have an affect on other parts of the codebase. They also demonstrated a willingness to work with contributors, as they took advantage of the labels for tagging issues for help.
As I'm sure most developers do, I notice small inaccuracies, bugs, glitches, or generally things out of place on occasional websites that I visit. And while working with and exploring the website for this project, our group noticed a few touches and improvements that we did not see any issues filed for. Most of these were more user experience related than any true bug or error, where a user might expect the html control to work a certain way.
It felt like we were helping (albiet in the smallest of ways) grow the development and success of the Open Food Network. In the end, this turned out to be a very rewarding and educational process to go through. While we were not able to make any significant code contributions, we were proud to get one pull request submitted and a few new issues filed for UX improvements. We saw first hand that this is a community which encourages and supports even the newest of contributors. As I watch our newely created issues get baked into the codebase (or sent to the grave), I'm constantly keeping my eyes open for another great repository to dive into.
-Nick Svetnicka