Preparing Our Group Presentation

This week, our group prepared the final presentation for our open source project. To make sure every member had the chance to share their own perspective, we divided the presentation into different sections so that each person could focus on a specific part of the project and their personal contributions.

Our group organization looked like this:

• Bella: Introduction
• Harry: Challenges
• Tianlang: Best Moment
• Willow: Lessons
• Vincent: Looking Back

For my part, I focused on looking back at my contributions to pandas throughout the semester. While preparing the slides, I realized that the presentation itself was also a reflection on my open source learning journey, not just a summary of what I did.

Getting Familiar with pandas Through Documentation

This week, our group project focused on contributing to open source, specifically the :contentReference[oaicite:0]{index=0} project.

To get started, I worked on two documentation pull requests:

• DOC: Fix observed default value in pivot_table docstring
• DOC: Fix non-standard default value formatting in Grouper docstring

Through these small contributions, I gradually became familiar with the structure of pandas. At first, the codebase felt overwhelming, but documentation turned out to be a great entry point.

Unlike jumping directly into complex logic, working on docstrings helped me understand how functions are organized, how parameters are defined, and how consistency is maintained across the library.

What is Zero-Knowledge (ZK)

This week, I explored the concept of zero-knowledge proofs (ZK), which is one of the most interesting ideas in modern cryptography.

At a high level, zero-knowledge allows one party to prove that a statement is true without revealing the underlying information. For example, instead of revealing a password, a user can prove that they know the password. Instead of disclosing income, someone could prove that their income is above a certain threshold.

This changes how we think about data. Traditionally, verification requires disclosure. With ZK, verification and privacy can coexist.

Why Companies Use Open Source

This week’s discussion focused on how companies use open source and why they actively participate in producing it.

Previously, I thought companies mainly used open source because it is free. However, the lecture changed my understanding. Today, companies use open source more for strategic reasons, such as avoiding vendor lock-in, accelerating development, and attracting talent.

Instead of building everything from scratch, companies can reuse existing infrastructure and focus on what makes them unique. This makes open source more of a strategic tool rather than just a cost-saving option.

Cathedral vs Bazaar in Practice

This week we learned about the cathedral vs bazaar model of development.

The cathedral model is more centralized and controlled, where a small group of developers carefully builds the system. In contrast, the bazaar model is open and collaborative, where anyone can contribute and development happens continuously.

In theory, most open source projects follow the bazaar model. However, from my experience, it is not completely “open.” While anyone can submit a pull request, maintainers still control what gets accepted. This creates a structure that is somewhere between cathedral and bazaar.

My Current Progress

At this point in the semester, I realized that my individual contribution to open source is still very limited.

Although our group has been exploring different projects and doing evaluations, I have not yet made a strong technical contribution on my own. Most of my work so far has been focused on understanding projects and setting up development environments.

This made me think more seriously about what I actually want to contribute to.

Comparing Experiences Across Groups

This week, we listened to reports from other groups about their open source project progress. One thing that stood out to me is that many groups are facing very similar challenges, regardless of which project they chose.

For example, several groups mentioned that the contribution process is much slower than they expected. Even after submitting a pull request, it can take a long time to receive feedback. In some cases, their PRs have not been reviewed at all. This is something our group can strongly relate to.

Another common issue is understanding large codebases. Many groups said that it takes a significant amount of time just to understand the structure of the project before making any meaningful contribution. This is also consistent with our experience, especially when working with a large project like pandas.

Working Toward a Project Choice

This week our group discussed which open source project we want to work on. The two main options we considered were freeCodeCamp and pandas. Some of my teammates suggested pandas because they have used it before in Python data analysis. However, I personally prefer freeCodeCamp.

One reason is the technical difficulty. From what I learned while researching both projects, pandas requires a deeper understanding of topics such as vectorization, memory layout, and the internal implementation of DataFrames. It also involves NumPy builds and sometimes even C or Cython compilation. For someone like me who does not have a very strong Python background, contributing to pandas may be more challenging.

On the other hand, freeCodeCamp is mainly based on JavaScript and web technologies. Although the setup process took some time, the overall development environment feels more approachable for beginners. I spent about one hour setting up the development environment following the wiki instructions. One difficulty was that the local machine setup requires the correct versions of Node.js, pnpm, Docker, and MongoDB, so it took some time to configure everything correctly. However, once the environment was set up, it became much easier to understand how the system runs.

I also forked the repository and prepared the development environment for freeCodeCamp:
https://github.com/Vincent08199/freeCodeCamp

My Expected Role in the Group Project

For our group project, I hope to contribute mainly to the backend logic and system structure. I am interested in understanding how different parts of a system interact and how software architecture is designed. Because of my background in computer science and some exposure to cryptography and security, I am also interested in exploring how security or data integrity could be considered in system design.

One challenge that may stand in the way is understanding a new codebase. Many open source or group projects already have large structures and many files, so it takes time to understand how everything connects. Another challenge may be coordinating work among teammates and making sure our work is organized properly through Git.

However, I believe I can contribute to the group by helping with debugging, organizing our Git workflow, and writing clear documentation. I also enjoy exploring technical details and reading source code, which may help the team understand complex parts of the project.

Comment on Student Presentations

This week we watched several student presentations of Chrome extensions. Overall, I was impressed by how confident most teams looked during their demos. Many groups clearly rehearsed their flow, so their presentations felt smooth and intentional.

One thing I noticed is that the strongest presentations were not always the most technically complex ones. Instead, the best teams clearly explained the problem → solution → demo flow. This made it much easier for the audience to follow.

Watching other groups also helped me see different design directions for browser extensions. Some teams focused on productivity, while others focused on user experience improvements. It expanded my view of what is possible on the Chrome extension platform.

Comment on the Git Exercises

This week’s Git exercises helped me move from using Git mechanically to understanding its internal model. Before this course, I often treated Git as a set of commands to memorize. Now I see it more as a structured system that manages the lifecycle of changes.

One concept that became much clearer is the three states of a file: modified, staged, and committed. The slides explain that a modified file has been changed but not recorded, a staged file is marked for the next snapshot, and a committed file is safely stored in the local Git database. This state model explains many behaviors that previously felt confusing.

The “loading dock” mental model was especially helpful for me. Thinking of the working directory as a workbench, the staging area as a filtering checkpoint, and the repository as the permanent record makes the workflow logically consistent. It also highlights why Git includes the staging step — it gives developers precise control over what enters each commit.

After practicing commands like git status, git add, and git log, I started to see Git less as a tool and more as an infrastructure layer for collaborative software development.

This week marked the first time I actively participated in building an open source project as part of a team. Instead of only learning concepts, we began applying open source practices through collaboration, discussion, and early design decisions.

Our project idea is QuickDelete, a browser extension that allows users to delete their browsing data with a single click. The goal is to make privacy protection simple and accessible for everyday users.

Open Source as a Social System

This week’s materials reinforced the idea that open source projects are not sustained by code alone, but by shared norms and communication practices. While code enables collaboration, it is social agreements—such as Codes of Conduct and transparent decision-making processes—that determine whether a community can function and grow sustainably.

When I first heard the term open source, it was not from a computer science class, but from playing PC games like Minecraft. In the Minecraft community, there is a strong culture of mods and modpacks, many of which are created and shared freely by players on the internet. These community contributions make the game more creative and enjoyable.

Because of experiences like this, I started to think of the internet itself as a large open source ecosystem — a place where people can share ideas, build on each other’s work, and collectively push technology forward.