Oppia 3 Presentation:

The Oppia 3 group mentioned that because of environment issues and slow build times, they had to shift their focus to dive into content creation and issue reporting. I found this pivot interesting, especially since it mirrors some of the flexibility we’ve had to practice in our own grouplike having to wait for feedback before moving forward. They also worked on the progress board, just like the Oppia group from last week, which made it clear that some challenges are shared across the teams that worked on the same project.They even incorporated AI-generated images, although they ran into trouble uploading them because Oppia didn’t clearly outline image size requirements. In the end, they completed a Manhattan tour exploration and another on Git version control one and even added voice contributions. Overall, it was cool seeing how they adapted and still made meaningful contributions despite the setbacks.

Reflections on Preswald and Hugging Face Projects

Preswald: Fast Progress in a New Project

Preswald’s project stood out because of how new it is, the codebase is still developing, which gave the team opportunities to build full features and work directly with the founders. They also improved the documentation, helping future contributors get started more easily. I also liked how they dealt with setbacks on the chatbot feature by building on existing code. Splitting into pairs early on helped their workflow and showed strong teamwork.

Hugging Face: Embracing Complexity

Hugging Face’s project was highly technical and focused on AI and machine learning. I don’t have much experience in that area, so I know I would have found it tough. But the team made solid contributions and clearly understood the challenges. Their visual workflow was helpful and reminded me of my own experience with Lucide. I also liked their slide about time-based strategy. Even though some parts were very technical, the depth of their work came through clearly.

Is Open Source a business model

Engineering Model vs. Business Model

In this video Stephen Walli opened up the debate with the assertion that “open source is not a business model” and instead said it was an engineering model. Walli emphasized that open source practices contribute immense value to the engineering side of software, but that translating that into business practice calls for more strategy and design. He referenced Paul Cormier’s famous quote that “Red Hat is not an open source company,it’s an enterprise software company that understands open source engineering.” It was interesting how he distinguished between the open source project as the technical foundation and the product (what customers buy), and warning not to confuse the two.

Open Source as Business Enabler

Jeff Borek provided a counter idea, saying that open source could actually function as a business model. He argues that open source licensing and collaboration frameworks have historically evolved to support new kinds of businesses, from Red Hat and SUSE to modern cloud-native companies like MongoDB and Elastic. While Borek agrees that open source alone doesn’t guarantee revenue, he insisted that it is a defining feature of alot of successful business strategies. He challenged the idea that open source is simply just a distribution method and stressed its role in shaping how value is delivered and monetized.

Something that Stood out: Mikko’s Law

Something that stuck with me from the video was the part of the discussion that revolved around community versus customers. Walli talked about Mikko’s Law which is “Your community has time and no money; your customers have money and no time.” This idea was used to debunk the idea that there’s a predictable conversion rate from open source users to paying customers.

Borek and Walli highlighted that companies have to tailor their strategy to engage with these two different groups separately. Community engagement builds user base and innovation, while direct customer engagement requires a separate, focused strategy around support, and relationship building.

The Cathedral and the Bazaar Reflection:

A quote I really liked was:

"The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better."

This one is about humility and collaboration. In open source especially, it’s not just about being the person who writes the most code or comes up with the biggest vision. Sometimes, the real skill is in listening and knowing when someone else has a better idea and being open enough to use it. It shifts the mindset from ownership to teamwork, which is key in any community-driven project.

Another quote I found meaningful was:

"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."

This one reminds me that simplicity is powerful. It’s easy to think that adding more features makes something better, but sometimes it just adds clutter. It’s a mindset that encourages intentional choices, not just piling things on.

While contributing to the Lucide project, I actually saw this idea in action. As I explored their site and design system, I noticed how almost every element felt intentional and nothing seemed excessive or just “there for looks.” It’s been hard to find things that could be removed without losing functionality, and honestly, that’s a sign of really strong design. It shows they’ve already put in the work of refining and removing the unnecessary.

Project Updates

The progress I have made in gthe group thus far is the discussion toward creating the peace sign icon. There have been a few different edits made to the icon itself to make sure that it is meeting the conditions and guidelines of a lucide icon. There were issues with the margin and a pixel-gap violation that other contributors brought to the attention of the issue. Now that those have been solved I will work on opening a pull request for the icon.

I really enjoyed the presentation. I appreciated hearing his perspective and journey of contribting to open source projects over the course of his academic career and outside of it as well. It was very relatable because he described taking on a big issue that he didnt initially think was a large task until he realized there were many additional layers to it.

Presentation Reflections

History of Open Source

Something I found really interesting was how early computer users had no textbooks, courses, or instructions and had to figure everything out themselves. The formation of the SHARE group in 1955 shows how collaboration and open problem-solving were essential from the start. It’s cool to see that even IBM encouraged sharing solutions, which contrasts with how proprietary software models later developed.

Project Reflection:

After teams were finalized, we have been working on narrowing down potential projects to contribute to. It seems that we all still want to take a somewhat creative approach, with a continued interest in JavaScript and TypeScript.

Initially, we had our sights set on Abbreve, which seemed like a viable option. The website appeared to be a friendly and accessible project for contributions. However, I was unable to attend the last class session, where the team ultimately decided to explore other options due to communication issues with the project’s maintainers.

Contribution Reflection

So far, my small contributions to Wikipedia have focused on improving grammar, clarity, and tone in articles. I have been able to make minor but meaningful edits, such as refining phrasing in the Kery James article to enhance readability and neutrality. Similarly, in the Gawaher article, I adjusted word choices to remove casual or potentially biased language, ensuring a more professional and objective tone.

What excites me most about working on an open-source project is the opportunity to collaborate with developers from different backgrounds and skill levels. I’m eager to gain hands-on experience with real-world codebases, contribute meaningful changes, and see how large-scale projects are maintained over time. Additionally, the potential impact of contributing to widely used software is really motivating.

I found the Git exercises we did incredibly helpful. Not only did I get to read about and hear explanations of various commands, but seeing the process in action and applying it to our project and other classes made the learning experience significantly more valuable.

I also really enjoyed seeing what everyone had been working on over the past week. It’s easy to become fixated on our own projects and feel proud of our progress, but viewing the creative and out-of-the-box ideas from others was truly inspiring. I found it fascinating that very few projects resembled each other, which highlights how each group brought a unique approach to the assignment.

My biggest takeaway from my group’s work was learning not to be afraid to challenge myself. For this project, I had little experience with the languages we used to build our extension. However, searching for resources and figuring things was incredibly rewarding. By the end, I gained more confidence in stepping outside my comfort zone and expanding my technical skill set. In this class, I hope to continue experimenting with languages I am less familiar with and push myself to grow even further.

My team and I have collaborated to update our individual files, which together form the foundation of our open-source project. For instance, I was responsible for drafting the LICENSE.md file, where I outlined the type of licensing our project would follow. After discussing it as a group, we collectively decided on the MIT license.

I also began initializing some key files. These files include manifest.json which defines the details about the extension, such as its name, version, permissions, and the files it uses. The other file was the content.js which our group will edit together to add the necessary features. During this time, I watched a few videos to better understand the process of manipulating webpages for Chrome extensions. The videos I referenced were:

• Chrome Extensions: Content Scripts - Programming with Text
• Chrome Extension Content Scripts

Code of Conduct:

A project’s Code of Conduct creates explicit guidelines for respectful and inclusive conduct, guaranteeing a friendly atmosphere for individuals from various backgrounds. It holds members responsible for their behavior and promotes positive communication. This type of document would be very helpful to other projects, particularly ones that get alot of participation.

Differences in Code of Conduct:

The Go Project’s Code of Conduct includes a detailed Conflict Resolution section, which encourages individuals to address issues directly and providing a clear process for reporting problems to project owners. It also outlines how conflicts are investigated and resolved. However, the Contributor Covenant mentions reporting abusive behavior but lacks a structured conflict resolution process. I think the Go Project includes this section to ensure clear and transparent handling of issues, especially given its large, diverse contributor population.

Open Source : Advantages and Disadvantages

When I hear the term open source, I think about access and how something is avaialable openly. One advantage of open source vs closed soure is the community collaboration which ultimately leads to continuous improvement and innovation within a project.

Another advantage would be that it is cost effective because it is normally free to use it reduces the cost for individuals who want to use and contirbute to it. A disadvantage to open source software would be that some open-source projects require technical expertise to install,