The Quiet Week

Open Source and COVID-19

With the world in a hectic state due to the COVID-19 pandemic rocking countries all over, it’s nice to see people all over the world doing what they can to contribute for the fight against this infection. And of course, being an open source class, open efforts regarding COVID-19 are some of our favorite ones due to their public nature and the collaborative spirit and unity that comes out of people coming together for the greater good.

Gil Yehuda’s Open Source Talk

More Rebasing

Git Rebasing/Merging Branches

In terms of incorporating new changes from a branch to another, including master, rebasing seems like a much more valuable tool than merging. The fact that rebasing makes the project history completely linear and without vague merge commits is incredibly useful for maintaining organization and clarity.

Invited Speaker: Vicky Steeves

Project Evaluations

Godot was the open source project some classmates and I evaluated this past week. It wasn’t a particularly challenging task, however I did learn a bit about what aspects (hint: not necessarily code) of a project are important for an open source project to flourish and gain contributors.

• Ease of organization helps—a lot. When I say ease of organization, I mean how easy is it for people to locate information about the project related to contributing, the community, and the like. For Godot, their website was richly detailed with many resources for presumptive contributors and users, and their GitHub repository included a concise, descriptive README that included links to all those documents pertaining to the “open-ness” of their project. Everything was easy to follow and got us up to speed really quickly.
• Source code documentation should be thorough. While Godot’s miscellaneous information regarding the project was spot on, their source code documentation was nearly non-existent. They had a docs page, but it seemed to be primarily focused on helping users use and experiment with the capabilities of the engine rather than for developers. Not having well-commented source code can make it tough for those who want to contribute to the source code itself because it won’t be readily apparent to them what a piece of code may do.

A Couple of Takeaways from Working in a Group

The extension my group and I are working on still has a ways to go. While I set up an overall structure of files for the extension, there is still quite a bit of code we have yet to write. Both our background script and content script are in their infancy, and currently our major goal is to correctly interact with the topSites API we are using in order to get our desired result. The other facet to our extension is a popup that executes the background script to kickstart the content script after the user clicks one of the buttons, but that seems to be having issues.

The keyword for me when it comes to “open source” is definitely “open” because it encompasses everything that makes open source software such an appealing idea to so many people, me included. It’s the opposite of a walled garden, allowing anyone and everyone to come in and contribute or use however they want. While this borderless nature can open the door for bad actors to wreak havoc, it is also integral to one of open source’s greatest strengths, it’s ability to foster collaboration. With the support of a strong community of contributors and users, open source software has the potential for near infinite iteration and improvement due to it being easily accesible and shareable. A passionate and collaboritve community can take open source software to the ends of the earth in a way that closed source projects would find hard to replicate. On the other hand, the life of an open source project fizzles out with the last fires of its community. I’m taking a class on open source software development to strengthen my knowledge on the ways of open source, so as to help me join these communities and contribute to open source projects in my own way.