This week was the final full week of classes at NYU. In spirit of this, many groups have already began presenting their final projects/presentations in our OSSD class. My group(Tuxemon) has yet to go, but we are scheduled to present this Friday(05/15/20). However, I got the courtesy to listen to several other groups present their projects this week. Both Monday and Wednesday were strictly dedicated to project presentations. The groups that I got to see present so far are: p5.js, FreeCodeCamp, Inky, OpenStates, and OpenFoodFacts. Overall, I thought all of the presentations were very well done and it seems everyone made a lot of progress in contributing to their respective projects. My favorite presentation was definitely FreeCodeCamp because I have been an avid user of FreeCodeCamp for a while now, so just hearing about improvements being made to FreeCodeCamp is a pleasurable experience. Furthermore, I plan on using their presentations as a guideline to make my group’s presentation high quality as well.

This week we gave another round of progress reports on our respective group projects. We got to hear more about where each person is currently at and their plans for the future in terms of their open source group project. Every one seemed to be making a lot of progress in their respective projects. One project that seemed to catch my eye was the p5.js project because I remember a classmate mentioning they translated over 20 code examples into Chinese, which I imagine was very annoying to do since javascript is a lot closer to English than it is to any other language.

This week we moved away from open source efforts regarding COVID-19 and moved towards Humanitarian Free and Open Source Projects(HFOSS) and open source business models. While all of the open source efforts regarding COVID-19 could be classified as HFOSS, we began to look at other projects outside of the scope of the virus as well. One HFOSS project that particularly caught my eye was Tidepool, which is a tool that helps clinicians and diabetic patients. Tidepool allows patients to see data from their insulin pump, blood glucose meter, and continuous glucose monitor all in one place. Tidepool has a massive code base and its user interface for both its product and website are very well polished.

This week in class we got to look at the remaining groups’(groups that didn’t present on Wednesday the week before) stand-up reports for their open source projects. There were only three groups left to present and my group was one of them. As previously mentioned, every group seems to be making progress on their respective projects. This includes: contacting the community, contributing issue requests, and making pull requests. Listening to these stand-up reports was definitely a reassuring experience as I was able to see that many groups share the same adversities and triumphs as mine when it comes to attempting to contribute to a large project.

Wikipedia is an online encyclopedia created and maintained as an open source project by a community of editors. It is the largest open source project with over 300,000 active users and over 85,000,000 registered users. Due to this volume, it is often considered the most important or “best” open source project currently in existence. However, to me, Wikipedia hasn’t played too much of an important role in my life. Ever since around middle school I was told to shy away from using Wikipedia as a source for my research projects since “anyone” could edit the information. Thus, I stuck to using peer reviewed websites and other resources on Google to do my research for most things. I will sometimes use Wikipedia to look up a movie summary/plot since I find their synopses to be really concise. As for my contributions to Wikipedia, I have yet to make any. Most of my contributions have been done on Github through either an issue request or pull request, but I do have plans to contribute to Wikipedia soon. I was thinking of looking at some things I’m interested in such as basketball (NBA) and video games.

This week we read the “Cathedral and the Bazaar” by Eric Raymond and discussed it in class. Overall, I found the essay to be quite interesting and it included a lot of great lessons that should be taken into account when designing something in the future. One important topic the essay talked about was the differences between a cathedral and a bazaar. These two terms are metaphors for development-models for projects (not necessarily open source). The cathedral model is a centralized effort, in which a defined group of developers is developing software under a closed roof. Nobody other than the designated group of people is involved in the project, and outside ideas are ignored. This is usually how companies develop proprietary software using the developers they hired to work for them. On the other hand, the bazaar is less restrictive and involves many people work on the same things at the same time. It’s chaotic, but surprisingly productive as shown through the development of Linux and Fetchmail. It’s hard to say which approach is better than the other, so it really comes down to the community/team you’re working with and the leader behind the operations themself.

In the week prior to spring break, we went over the differences between a rebase and merge in Git. However, this exploration of the differences between a rebase and merge was only a conceptual one. This week in class(Monday and Wednesday) we actually got the opportunity to practice using the commands in Git and see how the changes would be reflected in the file structure. We were split off into groups of two to three and were given a list of four exercises to complete. While ostensibly all of the exercises were trivial, they were in fact quite difficult once you actually started trying to do them. Much of this stemmed from my own unfamiliarity with Git and the command line in general. But after you expose yourself to it enough, a lot of the commands start feeling natural through rote memorization. Furthermore, Professor Joanna was very helpful when it came to roadblocks in progress, so none of my questions went unanswered.

This week was spring break, so we didn’t have class on Monday or Wednesday. I spent the week mostly just enjoying my spring break by hanging out with friends and playing basketball. However, towards the end of the break, my town shut down all public parks and started encouraging social distancing. Thus, I started playing video games and watching YouTube to entertain myself. As for open source contributions I made this week, I did take a look at other students’ week 7 blog posts to see if there were any typos. Of the ones that did have them, I raised an issue to the respective Github account and added the raised issue to my contributions file. I also began to think about the ways in which I want to contribute to the group open source project. With so many things I’m interested in, I want to try and dial it down to just a few ideas so I don’t spread myself too wide. Currently I’m thinking of contributing sprites/graphics, and some storyline functions through Python.

This week we looked at some more Git functionalities and were split up into groups for open source projects. On Monday, we went over the differences of merging and rebasing in Git. I’m fairly new to Git, so I found Monday’s class to be very useful. From what I understand, merging is a commit that represents every change that has occured on a branch since it was branched from the master. When you merge a branch and the master together, you combine the commits from the branch and the master. All the changes that were made on the branch are also put into the master(after merge conflicts are resolved if there are any). The downside to merging however, is that they can clutter up Git logs, and make it much more difficult to understand the flow of a project’s history. A rebase, if I recall correctly, can be understood as “moving the base of the branch to a different position.” Sort of like a redo - “I meant to start here.” It essentially plucks commits from a branch one by one (chronologically), and reattaches them to a different commit. This is useful in cases where we want to bring in the latest changes from the master branch, and don’t want to merge the master’s new commits into the branch.

This week we were given an opportunity to attend another Vicky Steeves talk. This time Vicky talked about the use of open source in the reproducibility of research. She also touched on the importance of preserving data, especially the data derived from research. What was really interesting to me was that she asked the class to raise their hand if they had their data backed up externally, and only Professor Joanna raised her hand. This was surprising because if Github or another cloud storage were to go down today, almost every one except those who are extremely careful with their data would lose a lot of their files. That means all of the researched data we gathered would be lost. That’s actually a big problem we face today as much of the data that was gathered in the past is lost and virtually unretrievable due to bad practices. Thus, Vicky stressed the importance of having a good open sourced platform to store data and methods of research.

This week we were given the opportunity to look at both good and bad examples of open source projects, and attend a talk about how Bloomberg contributes to open source projects. Now that we’re heading into week 6 of the semester, we need to start narrowing down our ideas on what projects to contribute to. Thus, these experiences this past week may serve as guides or galvanizers for ideas in the near future.

This past Wednesday, Deena Engel and Vicky Steeves came to our class to give a presentation on data processing and licensing. The presentation revolved around their specific experiences with open data. I found the talks to be very interesting because I was a data science intern this past summer. The talk exposed me a lot of new technology stacks and several public data resources. I definitely will end up using or at the very least looking into almost all of the resources mentioned in the presentation.

As mentioned in my previous blog post, my group and I were able to finish our extension project within two sittings. Both of these sittings were during the week 2/3-2/9, and so not much work was done this week on our browser extension. The only edits we made included double checking the license we were using, fixing typos in the text files, and crediting sources. None of these changes required too much time, so all of the work was done on our own times. Communication of these changes were done through text messaging.

This week my group members(Muying and Selamawit) and I worked on developing our own extension for Mozilla Firefox. We were really intrigued by the idea of being able to modify your own cursor using an extension, so we opted to do just that. We weren’t able to finish during Monday’s class, so we settled to meet around noon before Wednesday’s class to work on it. This was the first of our two total meetings. During this first meeting we narrowed our ideas down to one concrete idea and began working on it. The idea behind our extension was that it would give a drop down menu, in which 3 different emojis were provided (one of each of our favorite emojis) and upon clicking the button, the cursor would change to that emoji. We called this browser extension “Cursify.”

When I hear the term “open source,” I think of something that anyone can modify and distribute because it is publicly accessible. I also think about the open source licenses placed on the product to make it open source since just because a software has its source code online doesn’t necessarily make it open source. There are many advantages to open source. Open source software is often cheaper and has a longer lifespan than its proprietary peers because it relies on contributions from communities rather than a single company or author. A major disadvantage of open source is that it could be used for malicious purposes if it falls into the wrong person’s hands because the author of the product allows anyone to modify and distribute their product. I decided to register for a class about open source software development because I wanted familiarize myself with the idea of collaborating on a large scale project with a community.