Code Review Lab

Hello, friends! In this post I will examine two open-source software packages that have different licenses.

First, let’s look at what exactly is meant by “open-source software.” In the early years of digital computers, software was generally an academic concern. The focus was on research and problem-solving. To this end, software was usually distributed alongside its source code in order to allow users—who were, at the time, largely scientists and researchers—to examine and, if need be, to modify the software so that it would run on their particular systems.

As the market for computers grew, however, the nascent software development industry began to shift away from the open-source model, giving rise to proprietary, or “closed-source” (or “non-free”), software, which soon established itself as the norm. The reasons for this paradigm shift in software distribution are simple: if users must pay to purchase or to distribute software, then developers will have a strong monetary incentive to create better products, and so will trend to excellence—it’s the American dream and the very heart of capitalism. The dream was realized, ubiquitous giants such as Microsoft and Facebook and Google took form, and, as of today, proprietary software is, at least in the view of the laity, the standard.

But there have always existed developers and hobbyists who have shared their code, and who believed that a free and open approach to software development can be mutually beneficial to both developers and users; and, with the advent of the Internet, this community expanded and established channels of communication to foster a growing free software movement. There exist now a multitude of powerful and important open-source projects that offer an unrestrictive alternative to closed-source projects; moreover, there is some open-source software than has no proprietary equivalent.

A quick point must be made, I think, about the distinction between “open-source” software and “free software.” The first term is practical; the latter is political. We’re not about politics right now, but this leads us into the concept of licenses. Open-source software is released under a license that delineates what a user may or may not do with it. The purpose of licenses is twofold. Firstly, licenses can allow software to be used, manipulated, and distributed freely, effectively releasing it from the confines of its automatic copyright (copyright is, in general, a good thing by most accounts, but one must wonder what it says about us that freedom requires a license; imagine here Bond brandishing a license to free). Secondly, licenses can protect the freedom granted—for instance, some licenses specify that the software can be freely manipulated but also that programs derived from that software must be subject to the same condition.

Well, with that out of the way, we can move onto the meat and potatoes of this post: the examining of two open-source software packages that have different licenses.

The first open-source program we’ll look at is Firefox, a web browser named after an animal that is neither on fire nor a fox.

It’s a red panda.

Firefox was developed by the Mozilla Foundation, a non-profit organization that spearheads the Mozilla project, of which Firefox is a part. It is released under the Mozilla Public License.

The Firefox source code is hosted on Mozilla’s Mercurial (a distributed revision control tool) code repository, from where developers can download and build the Firefox package to analyze the workings of the program.

The process of contributing code for Firefox centers on Bugzilla, a web-based bug-tracking system to which users submit ‘bugs’ (which may be errors in the program’s functioning or simply features that the user would like to see implemented). Mozilla uses Bugzilla (if you’re curious about the -zilla, it does come from Godzilla, and it’s supposed to denote size and power and all things that are -zilla (but probably not the nuclear war metaphor)) for the development of many of its products: alongside Firefox are Thunderbird, SeaMonkey, etc. Each product has its own section, and all changes to the code are tracked by bugs in Bugzilla.

Each bug is submitted with various information specifying its current status, the product to which it is related, the relevant component of that product, etc. Moreover, each bug may be assigned to a person, who would then be responsible for work done on the bug. Most bugs are initially unassigned. To have a bug assigned to oneself, a person must post a message in the bug, declaring his or her intention to work on it and asking someone with bug-editing privileges (usually an experienced and trusted developer) to assign the bug. If a bug is already assigned, one may email the current assignee and cooperate on the project.

Code must be submitted in the form of a patch, which represents a single complete change. A user can attach a patch to a bug on Bugzilla and request that it be reviewed. As a module of the Mozilla project, Firefox is supervised by a module owner. For code to be accepted and integrated into the Firefox module, it must be reviewed and approved by the module owner or one of the owner’s designated peers. The user who develops the patch can upload it and flag it for feedback. Once enough feedback has been given and taken into account, and the user feels that the patch is ready to be implemented, he or she can attach it and flag it for review. A reviewer will then either accept or reject the patch. If the reviewer rejects it, he or she will provide further feedback and elaborate on what must be done in order to have the patch accepted. The user can then submit a modified patch and ask for another review, and this cycle continues until a patch is accepted. If the patch affects the Firefox UI, it must be reviewed further by a member of the Mozilla UX (User eXperience) team. Finally, if all is good, the patch is tested through a “try server,” and, if all is still good, the user can denote that the patch is ready to commit. Then, a user with commit access will push the patch to the repository, and, if it passes all the automated tests, it will be merged into the main branch and be released in the Nightly build, which is used for testing and which will eventually be finalized and released as an official build. Experienced contributors are encouraged to use a repository-based code-review system called MozReview to submit patches; the system is integrated with Bugzilla and simplifies the task of patching and committing for trusted users.

What stands out most about this process, I think, is its efficiency in consolidating code and ideas, and its simplicity. An issue can be brought up by one person, solved by another, and reviewed by yet another. The famous slowness of bureaucracy doesn’t exist here. Now, the system isn’t perfect—some issues are abandoned halfway through, some unresolved bugs date back years, and so on, but these are, by and large, limited to small, inconsequential features. Most important issues are either solved or being worked on.

Now let’s see how another side does it. Let’s look at GIMP, the GNU Image Manipulation Program, which is released under the GNU Public License. GIMP uses git (another distributed version control system), and its source code is hosted on the GNOME git repository.

GIMP uses a few mailing lists and an IRC channel to facilitate communication between developers. A new developer is encouraged to introduce himself or herself on IRC or one one of the mailing lists and to announce the proposed changes he or she is set to make. Then, after the developer makes those changes, he or she must generate a patch file using the git format-patch command. Afterwards, the patch must be sent to the mailing list along with a summary of what it does. The patch will then be reviewed and, if someone with sufficient administrator privileges says it’s okay, it will be accepted and merged into the code base.

The process is quite similar to that of Firefox developers. Indeed, GIMP also uses Bugzilla to keep track of bugs, and a developer may choose simply to submit his or her patch to Bugzilla rather than to the mailing list. The differences in their use of Bugzilla are only in the smaller details. Unlike Firefox bugs, GIMP bugs are not assigned to a particular person but to the GIMP section in general, and the history of a bug and the various stages in its fixing seem to be less strictly organized. This, I think, results from the size of each project and that of its respective development team. The GIMP team is smaller. Firefox, with its larger team and Mozilla’s financial backing, can afford the sort of meticulous precision that characterizes its patching cycle.

At the most basic level, the submission of code into an open-source project is the same regardless of the project or (at least in these two cases) the license. A developer writes code that is necessary or desirable, and submits it for consideration; someone in a position of authority reviews the code; and the code, if accepted, is merged into the software package.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s