Open Source Projects

Open source projects are very new to me and, at first, seemed very intimidating. However, upon looking into a few, I've noticed that the process is quite familiar. Within this post, I will be covering two open-source projects and what it is like to be a contributor to each, what the process entails, and what other roles are involved.

Mozilla Firefox

Mozilla Firefox is an open-source browser. It uses the “Mozilla Public License”, allowing users to copy, modify and distribute Firefox. The source code is managed with Mercurial. Also, the project makes use of Bugzilla, a web-based bug tracking system, and Phabricator, a software development collaboration tool, for code review.

To begin making a contribution, one may file a bug or claim an unassigned bug on Bugzilla. The bugs are divided into categories to make it easier for a contributor to find work that is within their skill range. Codetribute is a website that features mentored bugs that allow a contributor to have a mentor guide them through the entire process. The rest of the bugs are split into 2 other categories on Bugzilla: Good First Bugs, and Student Projects. Once one has decided on a bug they would like to work on, they are required to contact the bug submitter, reviewer, and/or component owner to more gain info on the issue and be made the assignee. From there, the contributor is free to make the required changes whilst following the project guidelines and is recommended to ensure their changes coincide with the Reviewer Checklist.

After the bug is fixed, it can be submitted for review which is where Phabricator is used. First, an appropriate reviewer must be found. If the contributor is being mentored, then either that mentor performs the review or they will recommend another reviewer. Otherwise, it is recommended to contact a reviewer who has previously worked (or currently working) on related functions or bugs. It is asked to allow 2 days for the reviewer to respond before contacting them again. Once reviewed, the reviewer will provide feedback and mark the issue report with a “Requested Changes” or “Accept Revision” action. Any requested changes are then expected to be made and this progress continues until the reviewer confirms that the patch is ready to be committed. Once ready, the reviewer can be asked to push the patch or “Land” the code which will mark the issue report as completed and close the bug. Level 3 access is required to “Land” code, which can only be requested after contributing and fixing a substantial number of bugs.

I looked through an assortment of closed patches and issue reports and they all vary due to importance and difficulty. I’ve seen bugs involve just 2 people and others that have involved up to 15. However, there are always 4 roles filled: Reporter, Assignee (Contributor), Reviewer, and Triage Owner. The reporter and assignee can be the same person if one chooses to work on a bug that they report. Reviews typically happen within a few days and any delay to how long the whole issue took to fix was directly impacted by the priority and difficulty of the bug. 

Apache

Now I will be looking at Apache projects under the “Apache Open-Source Software License”. Depending on the project, Apache projects use at least one bug tracking software, being either Bugzilla or JIRA. All projects can be found on their Project Listing Page. For the sake of this comparison, I will be looking at the Apache HADOOP project that uses JIRA for bug tracking. Each project has a website that documents how to contribute and all other resources for the project. However, one thing that all project have in common are mailing lists. Subscribing to a project’s mailing list is so important when working with Apache code, so much that one of their mottos is “If it didn’t happen on the mailing list, it didn’t happen.”. Many projects have multiple mailing lists for specific matters such as Issues, commits, and even one specifically for developers.

The source code for the Apache HADOOP project can be found on GitHub and Subversion. In order to begin contributing to an Apache project, a message can be sent to the developer mailing list, a bug can be filed, or one can pick up a pre-existing, unassigned bug in JIRA. If a message is sent to the mailing list, it is important to note that if the individual who sends the message is not subscribed to that list then the message undergoes extra screening before getting sent out. This can delay the message by up to 2 days so it is recommended to subscribe to the necessary mailing lists. After one is assigned a bug and their changes are made, unit tests must be made. Upon passing all unit testing, then a patch is ready to be created following the project conventions.

When this patch is attached to the issue report on JIRA, an automatic Jenkins test will be triggered which will add a success or failure to the report. Before even submitting one’s patch, it is highly recommended to test your own patch with the same tools that the Jenkins will use to ensure the code you are putting forward is functioning the way it is supposed to and as to not waste the time of a reviewer. Once a patch is attached to the report, a comment must be added to the report stating that it is ready for review. Pressing “Submit Patch” will trigger the Jenkins automatic testing that was mentioned before. Once given a success from Jenkins and a reviewer has set the report’s status to “Reviewed”, a commiter will then evaluate the patch within a few days by doing their own testing and will either commit or reject the patch.

Apache, similar to Firefox, also has opportunities for mentoring. However, the process to secure a mentor differs. The mentee must post an introduction of themselves identifying that they are looking for a mentor, their interests, skills, and what issue they would like to work on as well as how they would like to approach that issue on the appropriate mailing list. Mentors will reach out to them and once a mentor is chosen, the mentee must submit a Project Proposal for the mentor to sign off on.