I think there is not necessarily one type of development that is better than the other. It all depends on the type of project and the people involved. Some projects require a very high level of security, such as banking systems or government systems, where even a small error can cause a significant impact. These types of projects require a more Cathedral-like model. Other projects may benefit more from a Bazaar-like model, such as Linux or some community-driven projects like Better Genshin Impact, a game tool software I have been using.

AI coding tools could allow more people to get involved in open-source contributions, and they can also speed up code production, which favors the “Bazaar” side of development. However, AI tools may not necessarily support the idea that “given enough eyeballs, all bugs are shallow.” I have seen many open-source projects utilizing AI bots in issue triaging and code reviews, but I think they mainly assist human maintainers in understanding issues or PRs more easily, rather than truly providing more “eyeballs.” In the era of AI, we may actually need more Cathedral-like quality control than before.

We are mainly looking at issues in the repository. Most of them are about implementing features that Twitch has but Frosty does not yet support. I also found that many issues are performance-related, which are harder to approach. In the remaining weeks, I hope to continue making contributions and interacting with the community. We are quite interested in an issue that was proposed in 2023 and is still receiving replies as recently as last week.

I believe all the groups are making steady progress and meaningful contributions to their projects. People contribute in different ways: some groups focus on documentation-related contributions such as fixing broken links, providing translations, and improving tutorials, while others are more involved in code-based issues, such as the Keycloak group, where members have discussed their implementation plans and many technical details. Some groups also hold regular contributor meetings, and I think they benefit a lot from communicating directly with the maintainers.

It was nice to hear people’s rationale of choosing a particular project. Most people selected projects based on their familiarity with the programming languages or the project itself, such as Pandas or Affine. Others chose based on their interest in a specific field, like the Nanobot project. That particular project is only a month old but has already achieved over 30k stars. Because it is so new and popular, it iterates rapidly; issues open and close quickly, providing a constant stream of tasks for contributors.

In contrast, our project, frosty, is much smaller and moves at a slower pace. Compared to other groups, we have some overlap in our rationale, as we chose our project based on our familiarity with it and the feasibility of making contributions. We found that our project has plenty of room for improvement, and the issues seem easier to understand compared to the complex ones I’ve seen in projects like React or TypeScript.

Groups are also moving at different paces. Some have already dived into specific technical issues, while others—including us—are still working on our initial setups.

Regarding the tech stack, I have never coded in Dart or used Flutter before. However, given my experience with React Native and TypeScript, I don’t anticipate it being a major issue.

It’s inspiring to see such a wide range of interests among my classmates. I’m looking forward to hearing more about their experiences and the insights they gain as they progress through their projects.

We initially scanned the projects in the project evaluation repo and suggested some open source projects like jellyfin, kernelbench, curl. We look through each of them and found we had problem with setting up the development environment of jellyfin, and we also found kernelbench difficult and may require additional hardware requirements. According to our greep working aggrement, we don’t have a formal voting system. However, if people suggest something they should provide their rationale and other people should ackowledge that. People have known the reason of choosing the project and no one raises objections, so we now settled to frosty for twitch which looks beginner friendly and easy to make contributions. We see some issues on setting up the development environment now, but we are trying to help each other out.

I would like to work on a project that is active, beginner-friendly, and has clear documentation and a well-maintained workflow. What may stand in my way is having to understand an extensive codebase, as well as the steep learning curve that can come with contributing through development tools such as React or Vite. What I can contribute to the group project is my skills and experience in Python, Typescript, machine learning and data analysis.

For my small contributions, I have worked on Wikipedia and OpenStreetMap. I enjoy contributing to topics I’m personally interested in, mainly pages related to classical music and rock music. I started by simple edits like adding directing links, adding citations about my favorite composers or artists. I’m becoming more familiar with Wikipedia edit and I’m planning to adding new materials into their page. On OpenStreetMap, the biggest challenge has been that the satellite imagery is outdated; for example, the building where I live is still shown as a construction field on the map, which means I’m not able to make accurate updates yet. The contribution I’m most proud of is my edit to the Wikipedia page for the Russian composer Alexander Borodin, which is a relatively influential composer. I supplemented the page with an additional source, and the page has had over 7,000 views after my edit.

Takeaways from class projects

This week I really enjoyed watching other groups’ class projects. Some were genuinely funny and creative like MindMelt and AffirmMe, while others felt practical like tab_down, which I would seriously consider using it if they add a few more features.

My biggest takeaway from my own group work is that things can be harder than they seem. At the start, I assumed our extension would be relatively easy because our feature set is simple and similar extensions already exist online. In practice, I ran into several problems around persistence, which made me realize I need to strengthen my browser and javascript fundamentals.

From watching other groups, my biggest takeaway is that even if it’s difficult to build an extension with broad, high utility, because there are already many mature and polished extensions out there, you can still make your project stand out by being funny, specialized, or extremely focused on a specific community. The NYU wall extension is a great example: it’s simple, but it’s also unique and memorable because it targets a very specific context.

Reflections on the three OSS Summit videos

The three talks I watched showed different facets of what makes open source challenging and why it also works.

One idea that surprised me was the Hightower’s attitude toward competition and forking. He seemed not angry when a competing company forked his work—in fact, he sounded almost happy about it. His idea of “don’t build a moat around your project” is inspiring. If people can use it, adapt it, and even compete with it, that is a sign the project is valuable.

McLuckie’s talk acknowledged that AI can help with code generation, but he emphasized that it can also introduce problems, like pulling in deprecated dependencies, or quietly introducing vulnerabilities into the codebase. That increases the burden on maintainers. This reminded me to check AI generated code very carefully in my own projects and made me realize why many open source projects has strict policy in AI generated code and AI assisted workflow.

Torvalds’ conversation talked about about mature open source projects: the core work is often “calm and boring”. He also had a pragmatic but optimistic view toward AI. That’s a useful mindset for us too. Features are exciting, but code clarity, sustainability matter more if people want other people to actually use and contributing to their software.

Reflections on presentation style

The conference presentations were mostly casual in style, but “casual” didn’t mean unprepared. Many speakers were clearly trying to persuade the audience or “sell” an idea, and they sounded confident because they knew exactly what they wanted people to remember.

Hightower’s keynote felt like storytelling: conversational, value-driven, and built around a few memorable “principles”. McLuckie’s talk was more structured and argument-based. His slide was also mostly short bullets and a few headline statistics, left the audience with multiple concrete takeaways. The Linus Torvalds conversation had a different style, but it taught me something important too. A Q&A format can make a talk feel more relaxed and authentic, while still communicating serious ideas.

For my own presentation skills, the main weakness I want to fix is eye contact. When I get nervous, I tend to stare at my slides or my screen, and I forget to connect with the audience.

I would improve in several aspects. First is by knowing my content well enough to present without relying on slides. The conference speakers looked natural because they know what exactly they are talking. Second is improving the interactivity between audiences, like asking questions or trying to talk to the audience.

Navigating Git

I’m a regular Git user, but this in-class exercise exposed a few gaps in my workflow and helped me build a clearer mental model. For example, I rarely use git init because I usually start by cloning an existing repository. I also realized I’ve been relying on git add . too often simply because it’s convenient. After this week, I see why it should be used with caution: it’s easy to accidentally include unwanted files or unrelated changes, and that makes reviews and rollbacks harder.

Project evaluations and reflections

The projects I looked at varied a lot in size and activity level. Large projects like LangChain and Python are extremely active and fast-paced—issues can appear within the last hour and quickly attract multiple comments. Smaller projects tend to have fewer contributors and slower response times. In general, most communities felt welcoming, although I did notice that some maintainers in Neovim communicate more abruptly than others.

One consistent challenge is that many large projects are difficult to enter as a beginner. Some don’t have many “good first issues,” and even when those labels exist, the issues can still be confusing without more context. Some projects require substantial domain knowledge (for example, scikit-learn), and for ecosystems like React or JavaScript, it helps to already be a regular user of the library to contribute effectively.

What excites me most about contributing to open source is the idea of improving projects I genuinely use and care about—making even small changes that have real impact for other users. I’m also excited about collaborating with people who share similar interests, learning how to navigate a new codebase together, and improving through code review and discussion.

A few challenges feel very real:

1) Finding the right project — something active, beginner-friendly, and still realistically doable within the semester.
2) Understanding the codebase and issues — many projects have complex structures and workflows that are hard to grasp alone, especially at the beginning.

I plan to overcome them by asking questions, and prioritize tasks that are well-defined, testable and doable. I will also collaborate with my groupmates so we can all talk about our understanding of the codebase or a specific issue.

Our First Open Source Project

What I like most about collaboration is that people can genuinely learn from each other. When team members have different skills and mindsets, they bring perspectives that others might overlook. This week, our group had a healthy conversation that pushed our progress forward. We talked about what our browser extension would become. I got a lot of inspiration from my teammates about the basic implementation approach and several feature ideas, such as saving and sharing the highlight.

We also talked about how to write our documentation—such as the README, CONTRIBUTING guide, and Code of Conduct, and we decided to adapt the Contributor Covenant like what other projects do. After that, we planned the tasks we need to complete and divided the work.

We faced some common “first open-source project” questions that aren’t really about coding. We discussed what license we should use. We initially used the GNU license, but I don’t think it’s the best fit for this project but the MIT license might be more suitable. We realized that licensing is not just a formality—it affects how others can use, modify, and share our code. Another question was whether we should fork or clone the repository. We learned that if we’re working on a shared repository as a team, cloning makes sense for direct collaboration. Forking becomes more relevant when outside contributors want to propose changes through pull requests without write access.

During this process, I found myself paying attention to the non-code parts—like documentation and contribution workflow. A project can have great code, but if people don’t know how to set it up or how to contribute, it becomes difficult for others to join and help improve it.

My biggest contributions this week were mainly on the process and documentation side. I raised questions about how to choose an appropriate license and what contribution style we should follow. I also shared my opinions on what to include in the documentation.

One surprising thing I discovered is that I ended up spending more time on non-coding work than I expected. I also didn’t realize how important licensing is until we discussed and learned it in detail.

We haven’t dived into the implementation and coding details yet, but this week helped me understand how open-source collaboration works.

Why Code of Conduct?

Having a Code of Conduct helps create a diverse, safe, and welcoming environment. This is especially important for open source projects, because they bring together people from different backgrounds, abilities, and communication styles. For a community like Go, diversity is essential to thrive, and a Code of Conduct sets shared expectations so contributors can collaborate without constant friction.

A Code of Conduct also asks community members to be patient with beginners and discourages harassment or discrimination based on factors such as religion, gender, or identity. When people feel respected and safe, they are more likely to participate and collaborate effectively.

It also provides a mechanism for resolving conflicts when they arise. When normal discussion breaks down, Go’s document includes concrete reporting instructions and explains how reports are handled.

For these reasons, other projects would definitely benefit from having a Code of Conduct as well,especially projects that are public, accept outside contributions, or have active discussion spaces.

Adapted from the Contributor Covenant

At the bottom of Go’s Code of Conduct, Go notes that it is adapted from the Contributor Covenant. (go.dev) The Go Code of Conduct makes several changes to the Contributor Covenant.

One difference is that Go adds a section called “Gopher values,” which is not present in the Contributor Covenant. This makes sense because the Go community is not only setting standards for acceptable behavior, but also describing the culture it wants to encourage across the community.

Another important difference is that Go expands the scope beyond official project spaces. In Contributor Covenant v1.4, the scope focuses on project spaces and on public spaces when someone is representing the project. Go adds that the Code of Conduct may also apply outside project spaces when the project stewards reasonably believe someone’s behavior could negatively affect the community. This likely reflects the idea that harmful behavior outside the project can still impact community members and the community climate.

In addition to Go, Eclipse also adopts the Contributor Covenant. (Eclipse Code of Conduct) However, because the Eclipse Foundation is a large organization with many projects, working groups, and interest groups, its Code of Conduct has a different structure and focus. It does not have community-specific values like Go’s “Gopher values,” and it includes more formal governance language. For example, Eclipse specifies that a Conduct Committee is responsible for administering the Code of Conduct, while Go’s document places responsibility on “project maintainers” and the Go Project Stewards.

Different forms of Code of Conduct

Different from the examples above, the Sugar Labs Code of Conduct is based on the Ubuntu Code of Conduct. Compared to Go, Sugar Labs’ document feels more like general community collaboration guidance. It focuses on collaboration norms (being considerate and respectful, handling disagreements, and participating constructively) rather than listing unacceptable behaviors in detail or outlining a very clear enforcement process.

I also found something quite different in my favorite open source project, iNaturalist:
iNaturalist Community Guidelines

Go’s Code of Conduct is clearly based on the Contributor Covenant structure, while iNaturalist’s guidance is more platform-specific. It addresses issues that are unique to iNaturalist, such as how to communicate during disagreements about species identification and how to handle sensitive or disturbing content (for example, dead animals). This difference makes sense because iNaturalist has to consider real-world impacts on wildlife and nature in addition to interpersonal behavior.

Why Open Source?

When I hear the term open source, I think of projects like Linux, Python, and React.js—large-scale open-source software that has fundamentally shaped modern computing. These projects are built and maintained by communities: people report issues, submit pull requests, review code, and collectively improve the software over time.

Anyone can contribute to open-source projects, regardless of experience level. Contributions are not limited to writing code; they can also include fixing typos, improving documentation, providing translations, or reporting bugs. Open source also serves as a valuable learning resource. By reading real-world codebases, contributors can understand how software is structured and how specific features are implemented in practice.

At the same time, open-source projects come with challenges. Because contributors have different backgrounds and coding styles, the codebase may not always be perfectly consistent, well-maintained, or thoroughly documented. Security can also be a concern if configurations or dependencies are not carefully managed.

I registered for this class because I want to move from being a user of open-source software to an active contributor. Recently, I encountered a bug while using iNaturalist, and instead of simply working around it, I became interested in locating the source of the problem and attempting to fix it myself.

Four Projects That Influenced Me

1. iNaturalist

As an avid birder, I use iNaturalist almost daily to explore observation records, plan birding routes, and identify species. I also contribute to the platform by uploading my own observations. I strongly appreciate the idea behind the software: it connects the public with scientists through citizen science. The large-scale data contributed by users not only supports ecological research but also benefits enthusiasts and researchers like me.

2. Java (OpenJDK)

Java has been one of the primary programming languages I have used in coursework and personal projects to learn core computer science concepts. Beyond using the language itself, I have read parts of Java’s source code—such as the implementations of ArrayList and HashMap—to better understand design decisions and underlying principles in data structure implementation.

3. PyTorch

As a computer science and data science student, I frequently use PyTorch in machine learning–related courses and personal projects.

4. Wikipedia

I use Wikipedia to gain a basic understanding of things. I appreciate its collaborative nature and people’s efforts in maintaining such a huge shared knowledge base.