In watching the presentations throughout this week, I was surprised to see how each group had different experiences in working with their open source project. Some groups had ui/ux contributions while other groups struggled with their technology stack or getting more communication. A common thing I have seen is that every group has learned to be more patience and not to take constructive criticism to heart. However, all the challenges faced by each group did make a good story to tell and was fun hearing about it in the presentation. While there were problems, they were definitely learning opportunities like when the project community says that a feature isn’t needed after having already built it. Although most group probably won’t be continuing to contribute to their open source project, I am fairly certain that they will be contributing to other projects now that we have experience.

Open Source Initiatives

In the discussion about all the many non-software initiatives, it was interesting how diverse the practice can be. The idea of relying on the community to make a product or vision work isn’t novel but can be effective in banding people together for a common cause or interest. It can start with something as simple as wanting to share and develop a beer recipe. A good portion of the open source discussed were social good related services as well. Open source were used for these projects as a mean of increasing accessibility and gain community support. Like how Open Library aimed to increase accessibility of published works, open source can be used for more commercial means like Open Motors which seek to democratize electric vehicle production. Overall, I think it is cool to see how far reaching open source is even outside of software.

The Cathedral and the Bazaar

My opinion of the quotes and my favorite quote hasn’t been affected by the discussion and opinions voiced by other. I think most of my opinions aligns with that of my peers who had similar experiences developing software as me. It wasn’t surprising to see “Good programmers know what to write. Great ones know what to rewrite (and reuse),” as being the most favorited quote. It was brought up how most developing software isn’t about writing the code but going back to rewrite it. It is very unlikely and suspicious to get a working code on the first try, hence the importance of rewriting. Furthermore, modularity was also important and brought up as something being important to developing software. One thing that I think could result in more debate was about listening to end-users or customers in an open source project. On the one hand, the customer knows best as the end user but I can also see how it is also up to the benevolent dictator for life to shape their product. Overall, all of the quotes capture an aspect of what it takes to be a good software engineer as well as a contributor to an open source project.

Christopher Snider and Tidepool

In watching Christopher Snider present about Tidepool, I was charmed to see how much passion he has for it as well as other people who are part of Tidepool. As a result, I think there is a step up in terms of the effort put towards the end users and the user experience in comparison to open source used by enterprise. This isn’t surprising as Snider said almost everyone in Tidepool are diabetic or knows someone who is diabetic, being diabetic himself along with his wife. That isn’t to say Tidepool doesn’t operate as a business as it still requires funding. However, it does take on a secondary role with one source of their funding coming from a premium paid version of Tidepool. The goal is greater transparency for diabetics rather than management of cost and revenue. One thing about Tidepool I found to be interesting was how it started out as a fork of another application (don’t remember what it was called but maybe it was loop?). It was interesting how such a large application was built off of another open source project which now exist simultaneously at this large of a scale. This just attest to the nature of open source as a means of innovation and transparency which I have grown to appreciate.

In watching the three videos about open source/innersource in the business sphere, I found the practice of open source to be extremely important for progress and addressing the needs of a company/industry. Its main purpose and benefit seems to be breaking down organizational siloes and to improving communication and cooperation within the company. Companies are often divided into different divisions or teams and the use of open source principles would be efficient in bringing them together when there is a common task. As such, a project isn’t tackled individually and would be better developed with multiple perspectives, at a lower cost. This was proven through an example in the film industry. In working on films, workers often aren’t full time employees but rather work for the duration of their current film. After a film concludes, they would have to search for a new project elsewhere. Proprietary software would make it difficult for such workers to have to readjust themselves after moving around. Open source software would standardizes the application and increase knowledge portability from company to company. Furthermore, with several companies working together on a film, they would be able to create an application that is widely maintained, impactful, and at a low cost.

Over Spring break and the week after Spring break, I was able to make a contribution to Spicetify. I noticed that while many of their repositories has a contributing.md, their command line interface was lacking one. There wasn’t a flag for documentations in their issues so instead, I chose to notify the Spicetify team on discord. Using other Spicetify contributing.md as a reference and my own experience setting up the local development, I was able to create a draft and a pull request from it. There were many feedbacks in the pull request that I had to address and was a bit intimidating. Nonetheless, I was able to make the changes and continue the review. The maintainer even added a few changes herself as well. In the end, the pull request was merged and I was able to make my first contribution.

For the first week of group open source work, my goal was to start to familiarize myself with Spicetify. Being first contributors, my group decided that the best course of action right now was non-code based contributions. There are several repositories that Spicetify manages which are the cli, marketplace, and themes. We looked through all repositories and they seem to have independent GitHub based documentations but unify their documentation website. Some contributing.md were incomplete and outdated with broken links which Alex was able to promptly fix. None of the repositories seem to have a code of conduct which was surprising to me. This usually isn’t a good sign of a good open source project but it is also an opportunity to contribute one. Discord was the main source of communication which I joined to get an idea of what the community was like. Everyone seems friendly with even a discord bot to handle GitHub update notifications.

My thought about free/open source software and the people that work with them is that it is often developed through an interest in software rather than through a commercial interest. Linus Torvalds started the Linux kernel as a hobby and is continuing to work with open source software. Lately, he has developed a hobby for scuba diving and developed a open source software named subsurface for his hobby. In other cases, open source software were developed to address a need with many people focusing on making such software as accessible as possible. The business aspect isn’t always something that was considered when developing an open source software but has almost always come up for those who work on successful projects. It does give me a greater appreciation for those who contributed or led organization focusing on making software open and free.

In looking for different projects that I could contribute to, I found it to be quite a challenge. There are several factors that I am considering when looking for a project which are whether or not I can contribute to it, if I find it interesting, and if there is an active community with issues I can tackle. There are projects that I find to be interesting but would also find it to be difficult to contribute within the limited timeframe. There were many projects that I was considering contributing to that were using TypeScript. I am unsure whether TypeScript can be learned quickly if I already have experience with JavaScript and typed languages. The extra challenge of learning TypeScript would be something I have to keep in mind. I am still very uncertain as to what project I would contribute to but the discussion of Spicetify during class was interesting and will be considering that as well.

In watching Food Computer and Farming for the Future, I was surprised by how young the contributors were as well as the infrastructure they had to share information/knowledge. In taking this course, I realized just how wide spread open source software is so I wasn’t too surprised by anything in the video. However, the application of open source software was somewhat new to me. My experience with open source software mostly dealt with applications or technology and less so about things directly in the real world. As a computer scientist, I think I can definitely code open source software to address issues mentioned in all of the videos. While, it doesn’t have to deal with computer science directly, programming still played a big role in all of those project.

For this week’s work on creating a browser extension, I found it to be enjoyable. I got to learn about how to make a browser extension which I don’t have prior experience with. Other than creating the extension itself, there wasn’t any new tools I learned as I have a good amount of experience with Git already. For the extension I created with my group, I focused on creating new features on top of what was already there such as the range input and toggle button. Working with others went smoothly and there weren’t any issues. The project itself was relatively simple so there wasn’t much difficult as we focused more on the open source aspect as well. Everyone had their task to do and was able to discuss it with others. One thing I would probably work on more is writing better descriptions for commit messages and pull requests to make it easier for others to understand what I created.

For the in-class git exercise, I did not have any issues completing the activity as I am already familiar with git. I do know how to fork a repository but my experience with git has mostly been to creating a new branch for my work rather than a new repository. On the other hand, making contributions come from a forked repository makes more sense than creating a many new branch on the original repository.

The Code of Conduct exposed me to many different Code of Conducts which has changed my perspective of them. I especially appreciated those that goes in-depth as to what kind of behavior is acceptable and not acceptable as it shows the kind of community that is being fostered. I especially liked how Eclipse pointed out “It’s impossible to spell out every possible scenario that might be deemed a violation of this Code. Instead, we rely on one another’s good judgment to uphold a high standard of integrity within all Eclipse Spaces.” All of the Code of Conducts from Go, the Contributor Covenant, and Eclipse describes types of behavior as well as ways to report it, in the end, the responsibility still relies on the community.

My thought of open source is software that I can contribute to in some sort of way which I learned to be a very narrow view of an extensive concept. It is interesting to see how there is a difference between free and open software through a perspective that isn’t entirely focused on writing code. Open source provides both advantages and disadvantages. With open source software, vulnerabilities are found and fixed more frequently with more eyes to look at the code. On the other hand, with the code being more widely available, vulnerabilities are easier to exploit as well. My priority with open source software is being able to contribute to them and that is what I am hoping to learn through this class. I want to contribute to open source software but it can be intimidating so hopefully this course will introduce it to me.