Cathedral vs Bazaar model

After reading The Cathedral and the Bazaar, I better understood why open-source projects can grow so fast even without a highly centralized team. The “bazaar” model feels very different from the traditional idea that large software must be carefully built by only a small group of experts. Instead, the reading shows how open collaboration, frequent releases, and contributions from many people can make software stronger over time. I especially liked the idea that a project does not need to be perfect before being shared, because real improvement often comes from many different people looking at the same problem from different perspectives.

After spring break, I spent some time in Tampa, and it really helped me feel full of energy. Coming back this week, I felt more ready to focus on open source work.

This week, our group started to move into real contribution work instead of only participating in Discord chats and discussion posts in the repository. It felt exciting because this was the first time I was getting closer to actually fixing a real issue in a large project.

Spring break in Tampa 🌴☀️🌊

Exploring Other Teams’ Projects

This week, each group presented the final project they selected and their progress. One group mentioned that they were considering contributing to Pandas, a popular open source library used for data analysis in Python. Compared to our project, Pandas is more focused on data processing and backend functionality rather than user interface or application design. In contrast, our group selected AFFiNE, which is a productivity and knowledge management application that focuses more on document editing and user interface features.

This week I met several times with my teammates, and luckily everything went quite smoothly. First, we sat together and created our group working agreement. We decided our weekly meeting time and shared our previous group experiences, including both good examples and mistakes we want to avoid this time.

After that, we started looking for possible open source projects. Each member suggested several projects that might be interesting. Then we checked their repository pages and documentation to see whether they are beginner-friendly and suitable for new contributors.

Last week, I made my first formal PR. It was also my first real step into open source. At first, it was hard to find a repo that felt suitable. Many projects were too complex. Luckily, I met a very nice maintainer who replied kindly and clearly.

I improved the UI by adding a file path under the file name, implementing a fallback “Open File…” button, and creating a test set to help the maintainer check the feature. It was a small change, but it made the interface clearer. The biggest challenge was understanding the code structure before touching anything.

In the future, I hope to work on projects where I can improve UI and user experience. I know I can contribute careful UI changes and small improvements. The contribution I am most proud of is the fallback button — it looks simple, but I really thought about how users would use it.

Our first extension

During the past two weeks, my teammate and I built a fun Chrome extension called MindMelt (you can check our repo and install it!). The whole process was very interesting and helped me understand more clearly how open source projects work in real life. I learned not only how to write code together, but also how to discuss ideas, divide tasks, and solve problems as a team.

This week, different groups presented their extensions. I noticed that every idea, even small ones, can improve user experience. For example, one group designed an extra browser page so users do not need to switch tabs again and again. That idea was simple but very practical. Watching others made me realize that good projects usually start from small daily problems.

Git version control

This week we learned Git and version control workflow. Before this class, I always mixed Git and GitHub and did not really understand how Git works. After doing exercises like git add, git commit, and git log, I finally understand the process: modify → stage → commit.

I also tried Git on my own game project. It felt really helpful because I can save versions and go back if something breaks. This made me realize Git is not just theory, it is a real tool developers use every day.

Our Browser Add-on Activity

This week my teammates and I started our first steps toward an open-source project. We created and installed our very first Chrome extension called “Hello Team.” It was simple, but it helped me understand how browser extensions work and how different files connect to each other.

After that, we explored the Chrome Extensions Samples repository on GitHub. We found and read important files like README.md, LICENSE.md, CONTRIBUTING.md, and CODE_OF_CONDUCT.md. Through this process, I learned that open source is not only about writing code, but also about community and communication. I especially realized how important clear rules and respectful behavior are for collaboration.

Code of Conduct Reflection

Part 1

The Code of Conduct for the Go community lists many important ideas to prevent potential conflicts in future cooperation. It helps maintain a peaceful and friendly atmosphere in the community, and therefore helps the Go community stay active and full of vitality in the long term. For example, contributors may come from different countries and have different backgrounds. This document provides a baseline standard of behavior to reduce conflicts caused by different social values and communication styles. In my opinion, this kind of Code of Conduct can also benefit other projects, even small ones. Since every open source project involves cooperation, the ideas in the Go document give a good example of how to balance relationships between contributors.

Thoughts for Open Source

To me, open source is an idea about sharing code with the public so that anyone can access it, use it, and even modify it. This kind of sharing helps break monopolies over core technologies and encourages collaboration. I like to think of open source as an open menu. Everyone can see the recipe, improve the method, and share it with others. People can even open a restaurant and sell the dish, but they must give credit to the original author. In this way, open source supports both creativity and fairness.