Now, it’s time for presentations. My group didn’t get to do it this week, but the presentations that did happen were pretty fine, for the most part.

We are in the home stretch now! This week, I had a bit of a mental breakdown.

Project Update

Time for another project update! Stella and I have been navigating through the project and working on commits, and there are bright and dark spots to it. I’ve been having a relatively easy time talking to the maintainers of OpenFoodFacts, the project we’ve been working on, and getting my changes merged in. However, Stella has been struggling. They don’t know what’s up with one of the maintainer on the other side of the screen, but there has been one guy who has been pretty rude to them. This behavior has since lightened up, but it kinda makes me want to avoid some really nasty interactions (especially since I usually treat strangers like bears, or people who would want to screw my life over if I even attempted to prod and push them). It also caused me to end up doing more contributions than Stella for now.

This week, I got to do a really insightful reading about what makes open source successful in the first place: the Bazaar model. I also got to see how open source has basically been embraced by corporations and governments, though things do get tense over time for the former (because, of course the goals of corporations will never really be aligned with open source projects).

Long time no see blog viewers! I took a bit of a personal and school mandated break for a bit (because otherwise bad things can happen to people who just want to travel). This kind of meant that we had a few weeks to think about project goals and what issues to take on.

This week felt like connecting between the past and present of open source. We were originally going to have two presentations on open source–one involving banking and the financial world, and one involving the generative AI world, but the former was pushed back to a later time due to childcare duties.

This week, I found out that I was more delusional in my goals and that I should’ve been a bit more realistic on the goals and aspirations for the project I would be working on.

Back in my week 1 blog post, I discussed about how I kind of didn’t understand why people were motivated to work on open source projects. However, after learning about how and why open source projects are used for humanitarian and social good, as well as getting involved myself in open source projects, contributing to open source projects kind of makes sense now.

This week in class, we focused mainly on evaluating open source projects and seeing what open source projects would be appropriate given a person’s skillsets, timeframe for doing substantial changes to a project, and previous experience, as well as ensuring that I am working on an open source project and there is some sort of structure (e.g. code of conduct and contributing readme) going on to prevent toxicity in the project. After looking at multiple open source projects, I kind of felt a bit of concern in finding a project that works with my given constraints.

This week was a bit of everything. A bit of a Git command line lesson (but more of a refresher for me), and a lot of classmates showing off how good their JavaScript (and CSS surprisingly) skills are. It’s kinda weird to see how good my classmates’ presentation skills are (and they were probably better than mine)!

This week, I ended up getting grouped into a project team to build a simple Firefox extension. This involved a little bit of a crash course on creating both a simple and a more complicated browser extension, which was relatively easy to learn (in terms of basically the framework of the extensions), as well as refreshing my basic JS skills (as they haven’t really been used since 2023, but it was all good since the fundamentals of JS for browsers was relatively simple).

This week, I was looking into a few code of conduct document to see how open source project teams try to regulate themselves. A code of conduct document ultimately provides a way to codify procedures and rules of being a contributor for a certain open source project (or even closed source projects, though this would most be shown in a different type of document or way). It ultimately prevents higher-level people from abusing their powers by giving them a framework in which they should moderate activity on their open source project, and gives everyone else clear guardrails in what is and is not appropriate activity to do online.

Prior to my first Open Source class, I had a pretty strict definition of open source in terms of where it was appropriate to use that word (or not). I had this idea that it had to be some sort of software project that was freely available online, with some sort of source code available online and where people could pitch in their own code.

And to an extent, that was correct, although my first class session expanded my expectations of what counted as open source to include non-programming based things, like Wikipedia and OpenStreetMaps. This first class revealed how much more significant open source was to society beyond a technical field–for example, The Global Seed Vault can be counted as open source, and this vault revealed how important open source was. If there wasn’t any open source projects for plant seeds, humanity could potentially go down a very bad path of just using proprietary GMO seeds (that have some sort of better genetics compared to non-GMO seeds) produced by companies specializing in GMO seeds for all food resources and we would literally have our lives controlled by these companies. Essentially, open source provides an alternative resource to people who may not want or have the means of getting commercialized products.