Lab 1

Lab 1 - 09/01/20

For this lab, we were instructed to look at two open-source projects with separate licenses, research their code contribution process ("patching") and observe one complete iteration of this process. I felt that for this lab, it would be beneficial to select open source projects that I have used in the past, or projects that are still receiving updates. I hope that choosing projects this way allows me to provide the reader with a deeper understanding of what goes on behind the scenes.

1 - Bukkit (https://github.com/Bukkit/Bukkit)

Bukkit is an open-source modification API for the Java game Minecraft that allows developers to extend the functionality of their multiplayer server. I can understand the immediate skepticism some may have when they read this, perhaps discrediting this project because it is directed towards a video game. Allow me to convince you that Bukkit deserves a spot on this list.

Licensed under the GNU GPLv3, Bukkit's first public release occurred on December 21st, 2010. As of recent, Bukkit has now been in the public scope for ten years. With a surprising one-hundred-and-six contributors on github and sixty-seven releases, Bukkit's developers were clearly passionate. Two of Bukkit's most prolific developers, Nathan Adams (aka Dinnerbone) and Erik Broes (aka Grum) are now currently employed by Mojang, the company that developed Minecraft.

Bukkit is very clear as to how it handles contributions, anyone may contribute to the codebase freely. The GitHub page even provides a CONTRIBUTING.md guide, including a set of project 'goals' and an extremely informative flowchart for those who want their code approved. The pull requests submitted by the community are reviewed in standard GitHub fashion (although Bukkit declines to reveal just who is reviewing) and integrated into the codebase upon approval. This process makes sense for an application such as Bukkit, where users are finding issues and exploits as they use the API. The main downside to this process is how a seemingly simple fix, such as bendem's operator player inclusion (a two line fix) could take a disproportionate amount of time to integrate. The user in question, bendem, noticed that the command /deop, which removes the operator status from a player, was looping through players who were not operators. The simple fix he developed was to only look for operator players. This fix was tested and integrated successfully, albeit slowly.

Although I acknowledge the upsides and downsides of managing a project's pull requests in this way, I would agree that this is the best way to handle a project such as Bukkit. The cost of a longer approval/integration period is acceptable when it prevents the project from being filled with junk, or malicious code. As well, Bukkit has always been a community-driven project, so their integration process was created to maximize submissions from community members.

2 - OpenOffice (https://github.com/apache/openoffice)

OpenOffice is an open-source software suite that mimics the Microsoft Office brand of products. Featuring six applications, OpenOffice serves as a direct competitor to Microsft Office and LibreOffice. Being in development since 2012, OpenOffice is propelled by a small group of passionate individuals.

Licensed under the Apache License v2.0, the OpenOffice GitHub has a current total of six-thousand-nine-hundred-and-eighty-four commits, despite only seventeen contributors. Being developed by a small group does not deter OpenOffice from accepting contributors, in fact they provide a wiki page on their GitHub as a guide for how to contribute to the project, although the verification process is significantly more rigorous than Bukkit's highly community-focused approach.

Integration for OpenOffice is restricted to a small group of approved users. In rare cases, one of these approved users will merge a pull request instead of directly committing their code. There are currently only four open pull requests on the GitHub, and fifteen closed requests, of which approximately half were closed without approval. It's clear the main focus of the OpenOffice developers and the open-source community surrounding OpenOffice is to have code committed by approved users.

OpenOffice programs are relied upon by countless people every day. As well, OpenOffice has to live up to the Apache standard and code of conduct. Because of this, it makes sense to have users who wish to contribute to the project go through the proper verification. I do believe this process discourages users from submitting pull requests; despite being in development since 2012 the GitHub repo only has twenty-four pull requests as of January 2020. Perhaps the Apache OpenOffice wiki page could be appended to include a guide for those users who wish to submit code through a pull request, or other means of contacting the approved users who do the majority of the development.