I am a senior majoring in Computer Science and minoring in Psychology.
So far we have had many groups make their presentations. I found all of them to be interesting because they showed the different aspects of contributions that are important to an open source project, not just code. A common challenge that many groups faced is that making code contributions were difficult, especially because there are a lot of rules and guidelines when contributing to repositories.
This week, my group and I got a lot of progress done. Before this, we were working on some features for Preswald, like latex integration and a download button. We were able to get our features done and submit a PR. Since my group was presenting first, we decided to work on our slides early on. We had no previous presentation to go off of, so we were kind of worried about how we were going to present. To remedy this, we ran through a practice presentation and felt better afterwards, since we got comfortable about the parts that we each planned to cover.
This week, my group worked on finding new features to implement for Preswald. Since we started working in pairs, we’ve been able to get our PRs submitted for the features that we worked on. My partner and I worked on adding latex functionality to the project, and got the PR reviewed by the maintainers. Our next steps are to start implementing a new feature. My partner and I decided to add functionality to download the plots generated by plotly directly from the Preswald web app. This is so that users do not have to manually download the whole page as a pdf or manually crop the graphs.
The Cathedral and the Bazaar by Eric S Raymond is a really important essay that demonstrates the different types of open source projects. The main idea is that there are projects that operate like Cathedrals, where the developer community is small and mostly gets developed by the main project maintainers. On the other hand, there are Bazaars, which have many developers that all provide their own contributions with a project, and are less strict about certain things.
A lesson from the essay that relates to the contributions I’m doing now is “Plan to throw one away; you will, anyhow.”. This quote emphasizes the point that you will go through multiple iterations of what you’re working on, so striving for perfection from the very beginning is not the best approach. I’ve faced many challenges while contributing to my group’s project at first, and part of it was trying very hard to get my feature implemented perfectly at the first attempt. However, I eventually realized that what I was doing wasn’t working out well, and starting over from scratch was the best option. This ended up being the right choice as development was a lot more smoother after understanding the code base.
So far, my group has made good progress on contributing to the project we chose, Preswald. One of my group members was able to get a PR merged into the main projects repository, which included a significant feature. However, we have been facing issues in being able to finish most of our issues since there are many people eager to work on them. The issues that the other members and I were assigned to got PRs before we were able to submit our own. This was very demoralizing because we felt pressured to find a newer issue and work on it faster.
On a more positive note, we made a lot of progress on the original tasks that we got, so we understand the codebase a lot more compared to when we were starting. The task I got assigned to was to create a toggleable sidebar, so that users could choose if they can display their data with or without one.
This week, we had a presentation by Nick Vidal, who is from the OSI(Open Source Initiative). Nick introduced us to Open Source AI and what it entails. Mostly, we covered how open source AI is defined by OSI and projects that adhere to the definition, and also projects that appear to be open but actually go against some of the ideologies of open source.
Due to the nature of open source and AI, it is pretty difficult in creating a general consensus of what Open Source AI should be defined as. This is because AI is rapidly developing, and there will have to be new considerations on what counts as open or not.
During this week, we paired up with group members that aligned with our interests and searched for projects that we wanted to contribute to. My group and I had some ideas of projects from the beginning which included pygame-ce, pandas, and bokeh. If you noticed a pattern, then you’d be correct. All of these projects have a majority of python code. As a group, we are mostly experienced in python, so we decided to stick with projects that use it. We looked at other group evaluations and used them to base the skill requirement of pygame and pandas. We considered the projects, but realized that it might be hard to keep up with the pace of these projects while also trying to understand the well established code at the same time. With bokeh, we felt that it was the best for us at first because it was a simpler project in our opinion, but like pygame and pandas, there were a massive amount of issues in the tracker, and we weren’t sure if it was right for us.
Over the past few weeks, I have made 3 open source contributions. Two of them were for OpenStreetMap, and the third one was for Wikipedia.
My first contribution was adding missing bus stops to a bus line. I was surprised it wasn’t even noted on OpenStreetMap since many people use that bus line in that area, and all the other stops were locations on the map. I feel the most proud about this one because not only was it my first, but it is also really helpful for people who use the map to navigate and also for those who use open maps like these to gather information for their projects.
My second contribution was marking some stores as shut down and relocating the area of some. This also surprised me for the same reason as the first, that a popular area wasn’t updated for many years. This honestly made me realize how important it is to contribute to things and how impactful it can really be. If I had not updated that area, some people may have still thought that a store that had been closed for almost 10 years was still there.
Recently in class, we looked at a variety of open source projects. The project that my group was assigned to review was LMMS, a project that I had specifically mentioned earlier in the semester and am familiar with. As for the projects that my other group members looked at, some that caught my eye were Pygame, Godot, VS Code, and Musescore. These are all projects that I have interacted with/heard of at one point, so I believe that they align with my interests well.
Learning about git basics in class was really eye opening because before then, I was not aware of how it really worked besides the basic commands I had to use for my classes beforehand. Whenever I use git, sometimes it feels like if I do something wrong then I’d severely ruin whatever structure I have, but now I feel a bit more confident after seeing it in action more. Going over the working directory, staging area, and repository really helped me visualize how git works.
My group and I have been making good progress on our project. We initially were going to go with a simple game of rock, paper, scissors as our extension, but ultimately decided that we wanted something with more utility. We all decided that making a pomodoro timer would be a good idea for an extension.
As projects grow, there is a need for a code of conduct. Although many overlook them, it is a useful document that sets the standards for how people should interact and collaborate. One of these projects is Go, which lays out its standards clearly. There is a lot of focus on being cautious with your words, which is necessary when there is a large intersection of people with varying backgrounds. These kind of documents are beneficial to projects since they give collaborators a sense of safety in the project’s environment. It lets collaborators know whats tolerated or not, and gives them an outlet to express their concerns if they feel they are experiencing issues that breach the code of conduct. Also, it generally gives the project a more “official” look, which may prompt collaborators to behave in a more professional manner.
When I hear the term of “open source”, I think of software that has its source code widely available and free to use for anyone who wants to. I also tend to think of large collaborative projects and projects that deviate or add a twist to the source. Some advantages to open source is the development of new ideas and assistance with code writing. Many big projects would not exist today if it were not for passionate people who helped out in these open source projects.