For the first lab in my SPO600 class, I am tasked with exploring two open source software projects, each with difference licences, and investigating how contributions are made to them.

RethinkDB

The first open source software project I'd like to talk about is RethinkDB (licensed under Apache 2.0). On their website, they describe it by saying "RethinkDB pushes JSON to your apps in real-time." What this means, from a developer's perspective, is that it's a database that you don't really query. You connect to it, and it will tell you when the data you connected to has changed. This is a huge change from most database software, which you would have to query every few seconds or so to create a "real-time" experience for your users (think Facebook Messenger checking whether or not your friend replied to you yet). I think it's an interesting piece of software that I look forward to trying in my own hobby projects when I have time.

Source Code and Contributing

When it comes to developing RethinkDB, the community uses a Git repository on GitHub. Plans are conducted by creating issues on GitHub and submitting pull requests, having the community provide feedback, etc. This is a normal workflow for modern open source software. GitHub is basically a household name when it comes to open source these days (at least for us nerds). Have the source code and the planning in the same place with a nice web interface makes development active for this project. As I write this, the last contribution to the main branch (the "next" branch) was made just over one month ago.

Let's follow a particular bug and see the process of it being reported all the way to a fix being distributed. On October 10, 2016, GitHub user bsharpe reported an issue where a segfault was happening for them sporadically. Another user replied the same day, acknowledging that they understood the problem, but stating that they couldn't reproduce it. Fortunately, another GitHub user replied on October 26, 2016, that they figured out a query that reproduced it consistently. Between then and December 7, 2016, various GitHub users of the software offered suggestions and worked to figure out what was causing the issue. GitHub's tools like linking issues to each other helped them connect the puzzle together and more easily figure it out. As of December 7, 2016, the issue was figured out, and it was labeled as both "bug" and "high priority", presumably so that it would be added to the project maintainers' backlog of work, but a fix wasn't coded until February 2, 2017. At that point, the GitHub issue was closed, and the fix was eventually included in the next major release of the software in July of 2017. After the release, they left a comment on the GitHub issue noting that this fix had been included in the release.

Bug Fix Conclusion

This bug was handled with a lot of communication. The people working on posted with lots of detail about what they were doing and they even came back after the fix was released to log that in the issue. It was clear enough that a newbie like me was able to read the issue and know exactly what happened without having to look anywhere else! The timeline, however, was too long in my opinion. The bug was marked as a "high priority" and it did cause crashes for a small minority of users. Perhaps it could even affect a big user running a big business who could stand to lose a lot of money. It took 9 months to ship a fix for the bug from the date it was reported. I think they could have released the fix in a patch version rather than a major version. From what I understood about the issue, it didn't affect the API of the software at all, so it didn't need to wait until a major release.

GIMP

The second open source software project I explored was GIMP (licensed under the GNU General Public License), the de facto graphics program of Linux. This is the tool that has saved me tons of $$$ over the years since I didn't like the idea of paying Adobe for the privilege of using Photoshop. (Gotta save my money for the burritos on campus, right?) Let's see how easy it is to give back to this community.

Source Code and Contributing

The source code for this project is held in a Git repository controlled by the GNOME group. Their repositories follow the pattern "git://git.gnome.org/[project]". It's worth noting that unlike most open source projects started recently, this repository does not have a view through GitHub. The GNOME project has various web pages that explain to potential developers how to contribute. They use a variety of tools. To learn about commits that are taking place on the repository, developers subscribe to a read-only commits mailing list, which they're instructed to filter for the GNOME project they're interested in. For issue tracking, they use BugZilla.

Let's examine this bug. GNOME BugZilla user Susann Houndsville reported on September 3, 2017, that when they exported an image in a particular format with particular settings, the image they got had graphical artifacts. Another user responded within an hour that they were able to reproduce the bug on their system. Both users reported that they used Windows and reported which versions of Gimp they were using. Another user reported a few minutes after that they couldn't reproduce the bug, and that they were using Linux. It was soon discovered that the bug only affected the Windows build of the software, not the Linux build. On September 5, 2017, they figured out that this was caused by a bug with the GCC compiler (version 7.2). One of the users mentions that the GCC project's issue tracking system, also BugZilla, already had this bug reported. They decided that it wasn't worth working around this issue with the GCC compiler, and would instead be better to simply build with a newer version of the compiler when they fixed that bug. They added a note to the project to warn builders not to use this version of the compiler and marked the bug as resolved.

Bug Fix Conclusion

I was pleasantly surprised to see how quickly this bug was resolved. It was just 6 days between it being reported and resolved. It's worth noting however that this bug resolution didn't involve writing any actual code, so this may explain the quick resolution. The community seems active, competent, and friendly. It gives me the impression that any contributions to the GIMP project I make would be welcomed.

Conclusion

I can see from exploring these two bugs that I'm very thankful for GitHub existing. It took me a lot more time to get familiar with navigating the GNOME project's website and their BugZilla to find a bug to talk about. With GitHub, I'm familiar with it. Code and issues are in the same place, so it's easy to see the connection between them, and there's a good chance that the way one project works on their GitHub account will be similar to other projects. I can easily jump in and get an understanding of what their issues and plans are. I hope that projects consider moving to platforms like GitHub or GitLab that integrate the contribution process that way.


This was originally posted on the blog I used for my SPO600 class while studying at Seneca College.