Reflection on Our Group’s Presentation Last Week

Now that our group has finished our presentation on Lucide, I’ve had some time to think back on how it all went. One thing that really stood out to me was how smoothly we worked together. We divided everything up pretty equally, and everyone brought their own perspective and voice to the presentation. I was especially proud of how we talked through not just our contributions but also the setbacks we ran into. It made the whole thing feel more real and relatable.

One part of the project I was genuinely excited about was contributing icons, but that excitement took a bit of a hit when I got some pretty harsh feedback for missing one of the contribution guidelines. I understood the mistake, but the tone of the response felt more discouraging than constructive. It made it harder to stay motivated, especially since I was making the effort to contribute in good faith. It felt unnecessarily cold, and it left a bad taste in my mouth. It’s frustrating because the project itself is great, but those kinds of responses made the experience feel less welcoming than I expected. It reminded me how much a project’s community can affect your overall impression of it.

As for the actual presentation, I was a little worried we might be speaking too fast. It came up during our practice sessions, and I didn’t want us to sound rushed or make it hard for people to follow. But once we were up there, everything flowed better than I expected. The pacing ended up being just right, and we managed to cover everything within the time limit. I think our energy helped carry it through, and overall I’m really happy with how it turned out.

The Beginning of Presentations

This week, we officially began presentations! It’s been exciting seeing everyone’s projects come to life after so many weeks of hard work. I really enjoyed the presentation about Hugging Face. It was fascinating to learn more about the open source contributions people make to machine learning libraries. One slide that stood out to me showcased individual contributions, including PRs submitted and issues resolved. It really highlighted how much work goes into maintaining and improving these projects behind the scenes.

Group Project Update

Since our last meeting, our team has made steady progress on various contributions to the Lucide project. A few new icons were created and submitted, including a saxophone, butterfly, nursing mother, and an AI summary icon. In addition, multiple GitHub issues were opened, some suggesting new features, others focused on website improvements, and one of these issues already has a related pull request in review. There was also engagement with existing issues, including one related to React v19 and another older Svelte issue that may have useful applications elsewhere.

On the technical side, there was some exploration into extending Lucide to Qwik, though we concluded that the community support isn’t strong enough at this time to justify moving forward.

The Objective

This week, I watched Claude Warren’s insightful talk at DevWorld 2024, The Cathedral, the Bazaar, and the Coffeehouse. It not only revisited the core ideas of Eric S. Raymond’s classic essay, The Cathedral and the Bazaar, but also introduced a third metaphor—the Coffeehouse—as a lens to explore how open source communities collaborate today. These concepts helped me reflect on how my own group project operates, and gave me a clearer view of the evolving role of Open Source Program Offices (OSPOs) in companies.

The Project

Our group has been making steady progress on our open source contributions, and I’m proud of what I’ve been able to contribute so far. One of the things I worked on was fixing a broken and outdated info link related to using Lucide with Flutter. It might seem small, but it was important to update that documentation so other developers don’t run into confusion when integrating Lucide with Flutter projects. They have since archived Flutter compatibility.

Open Source AI’s Practicality

Nick Vidal’s presentation completely reshaped how I view open source AI. I used to think the idea of sharing all training data was overly idealistic and impractical. But his explanation that open source just means giving people instructions to reproduce the data, not handing over the raw data itself, totally changed my mind. Suddenly, open source AI feels doable, not just aspirational.

Update

So far, working with my group has been going pretty smoothly. Everyone’s been on the same page about wanting to work on a JavaScript/TypeScript-based open source project, which made it easier to narrow our focus early on. We’ve had good communication and were able to bounce ideas off of each other when looking at potential projects. However, we had to switch gears since it was looking like the owner of our chosen project would not be active in the rmerging process, and our goal is to have an ultimate contribution.

Introduction

Through this first half of the semester, I found it difficult to get started with open source contributions. I didn’t know where to start or what types of content I would be able to contribute to. However, once I got over the initial hurdle, I found that there are many projects out that fall into the category of non-code contributions. This made the process less intimidating to me as I made my initial contributions.

Contributing to digital platforms might seem like a small thing, but each action plays a role in shaping the online space we use every day. Whether it’s editing a Wikipedia page, updating a map, or adding content to an open-source project, every contribution helps improve the flow of information. In this post, I’ll share some of my recent contributions, the challenges I encountered, and what I’m most proud of.

Exploring Different Projects

After reviewing several open-source projects, one that stood out to me was Pygame. As someone interested in both game development and interactive applications, Pygame caught my attention because of its accessibility, strong community, and direct application to game design. I’ve worked with Python before, but I haven’t fully explored game development. Contributing to Pygame could be a great way to merge my existing programming skills with my interest in game mechanics.

Other projects I looked at had interesting goals but were either too complex for a first contribution or lacked clear documentation for onboarding new contributors. Pygame, on the other hand, has a well-organized structure, active maintainers, and beginner-friendly issues, making it a great place to start.

What Excites Me About Open Source

The most exciting part of working on an open-source project like Pygame is seeing real world impact. Many developers and students rely on Pygame for game development, so even a small contribution could make a difference. Additionally, collaborating with experienced developers is a huge learning opportunity I’ll get to see how large scale Python projects are managed, learn best practices, and improve my debugging skills.

Git Reflections

This week in class, we explored Git more deeply, covering topics like branching, merging, and reverting commit history. While I had some prior experience with committing, and pushing from my software engineering class, I found branching particularly interesting. The ability to work on a feature separately and then merge it into the main project is incredibly useful, especially in collaborative environments. However, I also realized how easily things can go wrong if you’re not careful. Merge conflicts and unintended changes can be frustrating, but this lecture showed experiments with different commands to gain confidence in using Git more effectively. The merge process felt seamless, but when we intentionally created conflicting changes, resolving them was more complex than I expected. Seeing Git highlight conflicts in fun.txt and manually choosing how to resolve them gave me a new appreciation for how real-world collaboration works in software development.

Another important takeaway was understanding the detached HEAD state—when we checked out a specific commit instead of a branch, it made it clear how Git keeps track of historical changes while allowing us to navigate through different points in time. Overall, these exercises helped demystify Git’s inner workings and reinforced best practices like committing often, using clear commit messages, and handling merge conflicts carefully.

Our Idea

For our browser extention, we decided on on Color1ze, a Chrome extension that allows users to customize text color on any loaded webpage. Users can choose from solid colors or an animated rainbow effect to enhance their browsing experience. We replaced the letter “i” with the number “1” to represent us being group one, thus portraying a fun way to integrate our ideawith our team number.

Essentially, users can:

• Select a solid color for text on a webpage.

• Apply a rainbow gradient effect to text dynamically.

• Toggle between different styles effortlessly.

We want to make reading webpages more fun and customizable, straying away from the conventions of the boring default black text color. With Color1ze, web page users will have control over the way they see webpage text. The hope is that users will be inclined to be more active with their online readings, thus promoting productivity and the power of choice in their web browsing. They will gain a sense of control over their viewership and feel more involved rather than mindlessly scrolling through the web.

The Importance of a Code of Conduct in Open Source Projects

Open source projects thrive on collaboration, and one of the core elements of maintaining a healthy and productive community is ensuring that participants behave respectfully. The Go project’s Code of Conduct serves as a clear set of guidelines that defines what is considered acceptable behavior within the community. The main benefit of having this type of document is that it provides both contributors and maintainers with a shared understanding of expectations. This can help prevent misunderstandings and conflicts, as everyone knows the rules upfront. A Code of Conduct also ensures that the environment remains inclusive, welcoming, and free of harassment, allowing people from diverse backgrounds to contribute without fear of mistreatment.

By outlining clear behavioral expectations, a Code of Conduct can foster a positive, collaborative environment, which in turn attracts more contributors. Without such guidelines, even a small disagreement can escalate into a toxic situation that harms the project’s reputation and discourages participation. This is why it’s beneficial for other projects, particularly those with growing communities or those under frequent scrutiny, to implement similar documents. A Code of Conduct can prevent toxic behavior before it becomes an issue, ensuring the community remains focused on the success of the project.

Comparing the Go Code of Conduct and the Contributor Covenant

When visiting the Contributor Covenant website, two key differences stand out between its Code of Conduct and the one adopted by the Go project. The first is that the Go project’s Code of Conduct contains an explicit statement of non-discrimination, encouraging diversity and inclusivity. While the Contributor Covenant similarly focuses on inclusivity, the Go project seems to have placed a stronger emphasis on diversity in its guidelines. The second difference lies in the Go project’s Code of Conduct including more specific actions in the event of violations, such as issuing formal warnings or revoking access to contributors who do not comply. The Contributor Covenant, while detailing similar steps, may be less specific in its examples of enforcement.

Open Source Discussion

When I hear the term “open source”, I think of publically availible code, free of charge, and modifiable by many people. To me, it represents endless possibilities of collaboration and distrubution. Unlike closed-source software, developers from all around the world have access to shared knowledge, and I think it is a way for the tech community to come together.

One of the most significant advantages of open-source software is its transparency. With open source, anyone can inspect the code to ensure it is secure, free of bugs, and compliant with their needs. This open collaboration often leads to better software quality because more eyes are on the code, constantly improving it. Also, it can be customized to meet specific needs, which is a significant advantage over closed-source software that might not be flexible enough for unique use cases. Closed-source software often has the development team have full control over the software and can ensure consistency. However, it also limits users to what the company behind the software decides to provide, thus decreasing real-time changes and creativity

That said, open source is not without its challenges. One potential problem with open-source projects is the lack of proper maintenance. Since open-source software relies on voluntary contributions, some projects may fall behind in updates, leaving users vulnerable to security issues or bugs. Furthermore, not all open-source projects have strong documentation, making it difficult for new users to jump in. Despite these challenges, the overall impact of open source has been helpful for the tech industry.

I decided to register for a class focused on open-source software development because I believe it will provide me with a deeper understanding of how these projects are maintained and developed. The opportunity to contribute to and learn from real-world open-source communities with help me in my professional career.