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:
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.
At the beginning of the semester, I was not familiar with pandas or large open source projects in general. The size of the codebase felt overwhelming, and even small tasks took much longer than I expected. I started with documentation PRs to learn the code structure, documentation style, contribution workflow, and CI system. These early PRs may seem simple, but they were extremely important because they helped me become comfortable with the basic process of contributing.
Later, I moved on to fixing a real bug in Series.combine_first, which was a much bigger step. This experience helped me better understand debugging, edge cases, and how to communicate with maintainers when responding to review comments. Instead of just changing code, I had to think carefully about how the fix might affect other parts of the library and how to test it properly.
Preparing the presentation made me realize that open source contribution is not only about writing code. It is also about understanding how large software projects are maintained collaboratively over time, and learning how to participate in that process respectfully and patiently.
Among the presentations this week, two groups especially stood out to me: the Frosty group and the p5.js group.
For the Frosty group, I was impressed by how user-oriented their contributions were. Brandon especially seemed very familiar with the platform and approached problems from the perspective of real users. For example, they worked on issues related to reset buttons and accent color customization. These improvements may look small technically, but they directly improve user experience, which is very important in real software projects. It reminded me that not every meaningful contribution has to be a complex algorithmic change. Sometimes, fixing the small details that users actually interact with can have just as much impact.
The p5.js group also gave a very strong presentation because their contributions were highly visual and easy to demonstrate. Since p5.js is a frontend-focused open source project, it was very intuitive to see the impact of their work directly on the webpage. This made their presentation engaging even for audience members who were not familiar with the underlying code.
One example I remember was related to language translation support. When the website failed to support certain translations, the problem immediately appeared visually on the webpage, making the issue easy to understand even for people unfamiliar with the codebase. This kind of clear, visible feedback is something that backend-heavy projects like pandas usually do not have, and it made me appreciate how different open source experiences can be depending on the project.
This week’s presentations helped me better understand that open source projects can be very different depending on the type of software and the community behind them.
Some projects focus heavily on backend logic and debugging, like pandas, while others focus more on user interaction and visual behavior, like p5.js or Frosty. The skills required, the way contributors interact with maintainers, and even the way progress is measured can vary significantly from one project to another. However, all of these contributions are valuable because they improve the usability and quality of the project in different ways.
Listening to other groups also made me realize how much I had grown over the semester without noticing it day by day. At the start, even reading an issue thread on GitHub felt confusing. Now, I can navigate a large repository, follow CI logs, and engage with maintainers’ feedback with much more confidence.
Overall, this week felt less like a normal class presentation and more like a summary of everything we learned about open source development throughout the semester. It was a good reminder that the value of this experience is not measured only by the number of merged PRs, but also by the understanding we gained about how real software is built and maintained in the open.
]]>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:
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.
After getting comfortable with the structure, I started looking for real issues.
This week, I found an issue:
BUG: Fix AttributeError in concat when result is Series
This was my first time trying to fix a real bug in pandas, not just documentation. I submitted a pull request:
What I found interesting is that even a “small bug” is not actually simple. It required:
Series behaves internallyconcat and combine_first interactTimestamp as names)This process made me realize that debugging in large systems is more about understanding assumptions than just fixing code.
After submitting the PR, I received feedback from the maintainers.
This was probably the most valuable part of the experience.
Instead of just telling me what is wrong, the maintainers guided me to:
It felt less like “fixing a bug” and more like learning how professional engineers think.
One new thing I learned during this process is pre-commit.
Pre-commit is a tool that runs automatic checks before your code is committed. It helps ensure that your changes follow the project’s standards.
In pandas, pre-commit can automatically:
This is important because in a large open-source project, maintainers cannot manually review every small detail.
Pre-commit acts as a first layer of quality control.
From my experience, it also improves developer efficiency. Instead of waiting for review comments about formatting or style, you can catch and fix them locally before pushing your code.
Based on maintainer feedback, I am still refining my bug fix.
This process is iterative:
This cycle made me realize that open source contribution is not about getting things right the first time. It is about gradually improving your solution through collaboration.
Compared to my previous exploration of zero-knowledge systems :contentReference[oaicite:1]{index=1}, contributing to pandas feels very different.
In ZK projects, the challenge is mathematical complexity.
In pandas, the challenge is system complexity:
Both require rigor, but in different ways.
]]>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.
What stood out to me is that ZK is not just a cryptographic trick, but a new model of trust.
In many systems today, trust depends on intermediaries. Banks, governments, and platforms verify information by collecting and storing data. However, this creates risks, including privacy leaks, data misuse, and security vulnerabilities.
Zero-knowledge shifts trust from institutions to mathematics. Instead of trusting an entity, we trust the correctness of a proof.
This is especially important in areas like finance and real estate, where sensitive data is involved. For example, instead of revealing full financial records, a user could prove eligibility for a loan. This reduces information exposure while still enabling decision-making.
In this sense, ZK can be seen as a foundational technology for building more secure and privacy-preserving systems.
To better understand how ZK is implemented in practice, I looked into the arkworks ecosystem, which is an open-source library for building zkSNARK systems.
One thing I realized is that arkworks is not a single library, but a layered system:
This structure reflects how complex ZK systems are. What looks like a simple “proof” at the application level is actually built on multiple layers of mathematical abstractions.
While exploring arkworks, I realized that contributing to this project is very different from contributing to something like pandas.
The technical barrier is significantly higher. To understand even a small part of the code, one needs knowledge of algebra, finite fields, and cryptographic protocols. This makes it harder for beginners to get started.
However, I also think this barrier is not accidental—it is necessary.
Security in cryptography depends on precision. A small mistake or ambiguity can lead to vulnerabilities. Unlike many other systems, where bugs may cause inconvenience, a bug in a cryptographic system can completely break security.
This idea became clearer when I looked at a discussion in arkworks about how to define the degree of the zero polynomial.
Mathematically, the degree of the zero polynomial is not well-defined (often treated as negative infinity or undefined). However, in code, returning a simple value like 0 is more convenient.
This creates a trade-off between mathematical correctness and programming simplicity.
In that discussion, I found myself leaning toward mathematical rigor. While returning 0 may simplify usage, it can break important properties such as:
deg(fg) = deg(f) + deg(g)
If such assumptions are violated, it may introduce subtle bugs, especially in complex systems.
For me, this reflects a broader principle in cryptographic engineering:
It is better to sacrifice convenience than to risk incorrectness.
Another interesting aspect is how open source plays a role in ZK development.
Because ZK systems are complex and rapidly evolving, many teams end up reimplementing similar components. This leads to duplication and fragmentation. Projects like arkworks aim to provide a shared infrastructure that others can build on.
In this sense, arkworks represents a “commodity layer” for cryptography, similar to how pandas serves as infrastructure for data analysis.
However, unlike typical open-source projects, contributing to such infrastructure requires not only programming skills, but also mathematical understanding.
This week changed how I think about both trust and open source.
Zero-knowledge shows that trust does not have to rely on institutions—it can be encoded in mathematics. At the same time, projects like arkworks demonstrate that building this kind of infrastructure requires a high level of rigor and collaboration.
For me, this also connects to my broader interest in real-world systems. In areas like finance or real estate, where trust and verification are critical, ZK could play an important role in reducing reliance on intermediaries while preserving privacy.
At the same time, contributing to these systems is not easy. It requires patience, learning, and a willingness to engage with complex ideas.
But I think that is exactly what makes it meaningful.
]]>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.
One idea that stood out to me is that open source itself is not a business model.
Even though the code is free, companies still make money by building services around it. For example, companies can sell support, offer hosted services (SaaS), or provide enterprise features on top of an open core.
This helped me understand that open source and profit are not contradictory. Instead, open source can actually enable sustainable business models.
The most interesting concept for me is the idea of “commodity vs differentiation.”
Companies no longer compete on basic infrastructure like operating systems, protocols, or data formats. These are considered “commodity layers.” Instead, they collaborate on these layers through open source.
At the same time, companies compete on the “differentiation layer,” such as user experience, product design, and algorithms.
This explains why companies are willing to contribute to open source. By sharing the cost of building common infrastructure, they can focus more resources on innovation.
This also answers a question I had before: why would companies contribute to open source instead of just using it?
From this week’s discussion, I think there are several reasons.
First, contributing allows companies to influence the direction of the project. Instead of depending on others, they can shape the tools they rely on.
Second, it reduces development costs. If multiple companies work on the same infrastructure, they do not need to duplicate effort.
Third, it helps build industry standards. This improves interoperability and makes it easier for systems to work together.
This idea actually relates to my own experience with pandas.
When I contributed to pandas, I was working on a small documentation issue. But now I realize that even small contributions are part of a much larger system. Many contributors together help maintain and improve a shared “commodity layer.”
At the same time, companies that use pandas are not competing on the library itself, but on what they build using it.
This week made me realize that open source is not just a development model, but also an industry strategy.
Different companies can collaborate on shared infrastructure, while still competing in the market. This balance between collaboration and competition is something I did not fully understand before.
It also changed how I think about the future. In areas like finance or real estate, I can imagine companies sharing core systems (such as data standards or blockchain infrastructure), while competing on financial products and services.
Overall, this week helped me see open source from a broader perspective, not just as code, but as a system that shapes how industries collaborate and compete.
]]>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.
Our group is working on pandas, and I was able to make my first contribution. I submitted a documentation pull request, which has already been accepted:
https://github.com/pandas-dev/pandas/pull/64989
This experience changed my perspective on open source. Before, I thought contributing to large projects like pandas was something very difficult or even unreachable. However, after completing this PR, I realized that contributions can start from small things, such as improving documentation or fixing minor configuration issues.
Sometimes, maintainers may not notice small details, and contributors can help improve those parts. This makes open source feel much more accessible than I initially thought.
I was surprised that almost every group has already made one or two pull requests. This shows that contributing to open source is not as “high-level” or exclusive as it seems.
At the same time, many groups reported similar challenges, such as slow PR reviews or difficulty understanding large codebases. This aligns with our experience as well.
One question I keep thinking about is sustainability. If people contribute to open source, how do they support themselves financially? It seems unrealistic for most contributors to rely entirely on open source work for income.
However, I still strongly support open source. I think collaboration is the only way to build large and meaningful systems. Open source allows many people to contribute together, which would not be possible in a fully closed model.
AI is making open source even more interesting.
On one hand, AI lowers the barrier to contribution. More people can generate code and participate in projects, which strengthens the bazaar model.
On the other hand, this may lead to a large increase in pull requests, many of which may not be deeply thought through. This puts more pressure on maintainers, since reviewing code is time-consuming and mentally demanding.
This made me think about a possible future role: an “AI maintainer.” If AI can help review pull requests, check code quality, and detect potential issues, it could significantly reduce the workload of human maintainers.
Personally, I do not think AI-generated code is a bad thing. The original motivation of open source is that one person cannot build everything alone. AI simply allows more people to participate. However, it also introduces risks, especially when contributors do not fully understand the system structure, which may lead to bugs or inconsistencies.
In the remaining weeks, I hope our group can:
Overall, this experience helped me realize that open source is not only about coding, but also about collaboration, patience, and system-level thinking.
]]>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.
For the second half of the semester, I decided to focus on contributing to Arkworks.
One reason is that I am very interested in Web3 and blockchain-related technologies. Compared to other projects, Arkworks feels more aligned with what I want to learn in the long term.
Arkworks is related to cryptography and zero-knowledge systems, which are important for many blockchain applications. I am especially curious about how these tools are used in tokenization and real-world asset (RWA) systems.
Another reason for choosing Arkworks is that I want to challenge myself.
Compared to projects like pandas or freeCodeCamp, Arkworks requires more mathematical and cryptographic understanding. This makes it harder, but also more meaningful from a learning perspective.
I know that contributing to this project will not be easy. I may need to spend time reading documentation, learning new concepts, and understanding unfamiliar code.
However, I think this is exactly the kind of challenge that can help me grow.
My goal is to make at least one meaningful contribution that can be accepted.
To achieve this, I plan to:
Even if the process is slow, I think it is important to take the first step.
This decision also reflects a shift in my mindset.
At the beginning, I was more focused on choosing “easier” projects to contribute to. Now, I care more about whether the project aligns with my long-term interests.
Even if I fail to get a PR accepted immediately, I think the learning process itself is valuable.
Overall, this week helped me clarify my direction and set a more concrete goal for the rest of the semester.
]]>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.
Hearing other groups’ experiences helped me realize that these challenges are not unique to our group. Instead, they are part of the normal process of contributing to open source projects.
One important takeaway is that open source contribution is not only about writing code. It also involves:
I also realized that timing is something we cannot fully control. Since most open source projects rely on volunteer maintainers, delays in reviewing PRs are expected.
Compared to other groups, I think our situation is quite similar. We also spent a lot of time setting up the environment and understanding the repository before making contributions.
One thing we might improve is aligning our expectations earlier. Some groups seemed more focused on smaller, achievable contributions, while we initially aimed at larger or more complex tasks. This made our progress feel slower.
Based on what I learned this week, I think our group should:
Overall, this week helped me adjust my expectations about open source. It is not a fast or straightforward process, but it is a valuable experience in understanding how real-world software development works.
]]>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
One challenge our group is currently facing is that our expectations for the project may be slightly different. Some members are more familiar with pandas and are interested in working on a data science related project, while others may prefer something more web-based like freeCodeCamp. Because of this, our group discussion is still ongoing.
Another issue is that our group might be a little ambitious. Both projects are large and complex open source projects, and we are still learning how to navigate their repositories and contribution guidelines. Different team members also have different levels of familiarity with these tools and technologies.
To resolve this, I think our group needs to communicate more clearly about our strengths and learning goals. Instead of only focusing on the popularity of a project, we should also consider whether the project is realistic for us to contribute to within the course timeline.
Personally, I still lean toward freeCodeCamp because it seems easier to get started and may allow us to make meaningful contributions earlier. However, I am open to discussing with the group and finding a project that everyone feels comfortable working on.
For the next step, I plan to continue exploring the freeCodeCamp repository and look for beginner-friendly issues. At the same time, our group will keep discussing which project fits our team best.
]]>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.
This week I made several small contributions during the project evaluation activities. In class, my partner and I worked on evaluating the iGraph open source project. We first tried using AI tools to generate an evaluation draft and then manually verified the information by searching through the GitHub repository.
During this process, I realized that AI can help generate a basic structure, but it often makes mistakes with factual details. For example, the number of commits and contributors was sometimes incorrect, and the latest commit information seemed to have delays. Some of the links generated by AI were also inaccurate. Because of this, we had to manually check the GitHub repository to confirm the information.
I also tried to explore another open source project called Arkworks, and looked at an issue related to improving documentation for Pedersen hash functions. However, I quickly realized that contributing to this project requires stronger mathematical knowledge, especially in cryptography and elliptic curve concepts. Because of this gap, the process was challenging. I tried to read online documentation and quickly summarize the concepts to better understand the problem.
The contribution I am most proud of is that I actively tried to engage with the open source community. Even though my contributions are still small, exploring repositories, reading issues, and trying to understand real problems gave me a better understanding of how collaboration works in open source communities.
One open source project I am interested in contributing to is Arkworks. Arkworks is a Rust-based ecosystem that provides tools for cryptography and zero-knowledge proof systems. The project focuses on building efficient cryptographic primitives such as elliptic curves, hash functions, and proof systems that are widely used in blockchain and privacy-preserving technologies.
This project interests me because I have been studying cryptography at NYU and have learned about concepts such as hash functions, digital signatures, and secure protocols. Arkworks represents a practical implementation of many of these theoretical ideas. Contributing to such a project could help me understand how cryptographic systems are implemented in real-world software.
However, I also recognize that contributing to Arkworks will be challenging because it requires strong mathematical understanding, especially in algebra and elliptic curve cryptography. To prepare for this, I plan to spend more time reading documentation and learning the mathematical background behind these systems.
Even if my contributions start with small improvements such as documentation or clarifying explanations, participating in this project would allow me to gradually build deeper knowledge in cryptography and open source development.
]]>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.
Our group presented QuickHistory this week. The demo did not go exactly as planned, but it was a valuable learning experience.
During the first part of the demo, we deleted some browsing history to create a clean example. However, this accidentally removed the exact data we needed later in the presentation. When we asked the AI agent to search, there was nothing to find. In the moment it felt awkward, but in hindsight it was actually a useful lesson.
The biggest takeaway for me is:
Demo reliability is part of the product.
Even if the system works technically, the presentation can fail without careful planning. In the future, I will always:
This experience made me realize that engineering and presentation discipline go hand in hand.
This talk stood out to me the most. I had not fully considered that AI-assisted coding could also scale malicious package creation. If AI helps developers move faster, it can also help attackers move faster.
His emphasis on provenance tools like Sigstore and SBOMs makes a lot of sense. As AI-generated code becomes more common, being able to trace where code comes from will become critical for security.
I really liked his metaphor comparing open-source maintainers to quiet craftsmen. It highlights how much invisible labor exists behind the software we use every day.
The HashiCorp fork discussion was especially interesting. It reminded me that open source is fundamentally about shared ownership and freedom to fork, even when it feels uncomfortable.
Torvalds’ calm and pragmatic tone was refreshing. His view that AI is like “auto-correct on steroids” feels realistic. AI is powerful for productivity, but human judgment is still essential.
What I found most interesting is his comment that a mature project becomes “calm and boring.” That changed how I think about software maturity — stability itself is a sign of success.
Comparing student presentations with OSS conference talks, the biggest difference is storytelling.
Conference speakers:
Student presentations (including ours):
This week made me realize that strong technical content is not enough. Delivery matters.
Going forward, I want to improve my presentation style in three ways:
1. Start with the human problem
Instead of opening with features, I want to frame the real user pain first.
2. Use clearer narrative flow
Problem → frustration → solution → demo → impact.
3. Rehearse demos more rigorously
Technical correctness must be paired with presentation reliability.
Overall, this week helped me see open source work from both the technical and communication perspectives. Building good software is important, but explaining it clearly is just as critical.
]]>