Week 11: Thoughts on the Cathedral and the Bazaar, and notes on Frosty progress

Thoughts on the Cathedral vs Bazaar Model

I feel that the Bazaar model is superior. Even in the ideal theoretical world of the cathedral model, where small groups develop a system behind closed doors, they are still going to be utilizing tooling from larger systems and groups. So I don’t believe in this individual siloed approach where any time, no matter how large, can build something and make it wonderful on their own. Also just working on polishing a version within a group can lead to group think especially in regard to over-engineering features that real users don’t want. The Bazaar model is also more connected to the spirit of software, as it allows many people, to contribute but to be free in exploring what they desire and are curious to work and contribute on. It is curiosity that allows individuals to really dive and explore novel architectures, and that can’t exist if developers are stuck behind closed doors.

Effect of AI Tools on Development

I think that AI tools accelerate this Bazaar-like development loop. Even if the first iteration is largely slop and not scalable, being able to use AI to quickly prototype a new feature and get user feedback accelerates this loop and thus lowers the barrier to adding new features. Another useful aspect is that AI allows more junior developers to talk to it and describe how a codebase works, that paired with reading the code, helps new developers onboard quicker without using the time of experienced maintainers.

Progress in Frosty Project

Submitted PR to fix the double play button issue and currently working on getting the audio working.

Outlook for Frosty Project

Though it appears that the audio change will have to be larger as the current way that the system works prevents audio from being played when the app is closed either on the lock or home screen.

Reports on other Groups

I appreciated how the Pandas’s project group focused on adding example usage for the project, and how that would be helpful without having to write any code.

Read More

Week 10: Fixing errors in Frosty

Exploring using Frosty

I knew that I wanted to fix issues and or add new features, but I recognized that I needed to think from first principles by becoming an actual user of Frosty. After all, being a genuine user of the product is really the only way to get a sense for what users want, which in turn helps me avoid over-engineering potential features that no one actually wants. Frosty adds support for browser extension features that do not exist on the native twitch mobile app. I first tried out these browser extensions while watching twitch streamers and really enjoyed how the features worked with the stream and made it overall more enjoyable. Then trying the native mobile app, the absence of these browser extension features became apparent and the interacting experience was significantly worse. Finally, trying out Frosty I found that I regained the experience that I had on the browser based streams, however there was one extension that was glaringly obvious.

Encountering the Error

I had heard about the double play button error from the issues list on github, but it felt different when I actually encountered it as a user. When I or any other user clicks into a stream, the error appears as a giant play button overlaying the normal phone which prevents the user from clicking the real play button and obscures the video frame. It is quite annoying as every single time you click into a stream, you get this error which makes the entire project seem buggy and hurts the user experience.

Fixing the Double Play Button Error

In terms of fixing this error, I first isolated that the video and navigation loading was in the file video_store.dart. Then I found that currently the twitch native overlay, which is the origin of the giant double play button, was only being hidden after the video was already initialized. This meant that the double play button was always occurring. My fix was to hide the default overlay immediately on the initialization of the video. I have an active PR for this fix, but have yet to hear back.

Read More

Week 7: Group Project Progress

How We Decided on Our Project

In terms of finding our project, we first took a look at the projects that the class had already made evaluations of. Though when reviewing them, we found that these large projects like VSCode would be difficult to understand and thus make useful fixes/changes, and that due to their size there would be a large gap in time between submitting a PR and getting feedback on it. So we then looked at projects that we personally found interesting, where I brought up Curl. Curl was interesting but we then found that the project was currently not accepting new PRs so we would have to wait weeks to get feedback. Then another member suggested Frosty as they were familiar with using Twitch extensions. We looked through the GitHub and found that maintainers were very active and that the project wasn’t too large, and everyone felt that they could understand it.

Group Work So Far

So far we have decided on the project of Frosty, with all of the members currently working on installing and getting it running. We had one standup where we decided on this action item and discussed issues that we might be having with getting it running.

Obstacles and How We Plan to Resolve Them

The current obstacle is getting Frosty running, so we will communicate our issues to each other on our group Discord server to resolve them. We will also work to begin mapping out the repository and understanding it. Then we can transition to looking at issues and making PRs.

Read More

Week 6: Project Evaluation

The kind of projects that I am looking for

I want to work on the performance aspect of the project for the group. Though I do have to first fully understand the components of the project end to end in order to do that. So I will have to get the change working completely without issues before working on optimizing it.

Read More

Week 5: Evaluating Extension Presentations

Thoughts about different projects that I have looked at so far:

I thought that the youtube video random interruption extension was interesting and exciting as it showcased advanced video techniques. I definitely felt inspired by this, as my presentation was only cycling a background photo. Also since I only had one partner in my group, I appreciated how multiple members could bring their own perspective which could lead to better or ideas, or more interesting presentations.

Three Videos Review

In Kelsey Hightower’s keynote on open source, he emphasized that open source is really about building a community around the software, as opposed to just maintaining a code base. Craig McLuckie’s talk on managing supply chain risk in a world of AI-assisted developers illustrated to me how the speed that is often seen as a useful feature of AI generated code, could actually be a bug as it slows down teams that ultimately need to verify them. I did enjoy Linus’s talk and how he went deep on technical topics.

OSS Conference Presentation Styles

From viewing these presentations I now see how vital communication is when trying to explain technical concepts. Some presenters had moments where they suddenly spoke deeply on a topic, but it wasn’t prepped well so it came off as interesting, but unless I had prior knowledge I wouldn’t be able to really understand it. Therefore, for my presentations, I should try to create scaffolding that enables viewers to understand each component of my talk in a structured way.

Read More

Week 4: Evaluating Open Source Projects

Thoughts about different projects that I have looked at so far:

Even though I don’t think that I will choose scikit-learn as my project, I did find it interesting how even a large project would still require two core developers to approve each PR. I’m impressed that they require that and still have the issue fix cadence of about 2 issues fixed per day. Also seeing the documentation PRs, I can see that there are different ways and even non-coding ways to contribute to open source.

What I am most excited about regarding working on an open source project:

I am most excited to be a part of the community of a project, as I owe a lot to the open source projects that are the foundations of the tech stacks that I use.

Biggest potential challenge and my plan to work through it:

It would have to be getting the entire project in context, since I would want to fully understand the repo and how each component of the repo functions and interacts with the others. I plan on working through it by running the project and creating diagrams and reading the documentation and rationales behind the repo design.

Read More

Week 3: Building an Open Source Firefox Extension

Progress

My group, red team, is building a Firefox extension that replaces the new tab page with a background image of NYU. The main idea is that when a user opens a new tab, they will see a different photo of campus. Initially I was working on creating the README.md file in order to give new users and potential contributors an idea for the motivation and general purpose of the project. Additionally I worked on getting the functionality working and gathering images of NYU to use.

Problems

One challenge that I’ve faced is that I’m not familiar with javascript, so I’ve been having to learn more about the language as I work on these features.

Collaboration and Contributions

We collectively decided on this idea and now I’m working on getting the initial functionality working.

Surprises

I’d never worked on or thought much about how browser extensions worked, so I didn’t have a sense for what was possible. But through working on this I’ve seen that there are a lot of resources available and the potential is exciting.

Read More

Week 2: Codes of Conduct

Go’s Code of Conduct

The code of conduct for the go programming language emphasizes the core values that enable people with different backgrounds and communication styles to collaborate productively. Its main benefit arises from being able to specify expected behavior so that contributors will know, or at least should know, how to conduct themselves and what actions wouldn’t be tolerated in the community. Also, providing an explicit conflict resolution mechanism decreases the strain on community members as the path towards a resolution is clear and doesn’t require a case by case assessment for what is acceptable.

I think that any project, be it software or physical would benefit from having an explicit code of conduct. As conflict is inevitable when dealing with human collaborators and without clear standards, it’s not always clear how to de-escalate and resolve issues, which takes time away from community organizers and overall project quality would take a hit as a result of that. Also without guidelines on what is and isn’t acceptable dialogue and conduct, new community members, even if not malicious, could get the wrong idea and act in a way that goes against the spirit of the community.

When comparing the contributor covenant to Go’s code of conduct, it’s evident that Go went far deeper in its initial values section than the contributor covenant. These explicit and detailed values, especially in regards to “Be constructive”, likely illustrate how the Go community focuses on aspirational ideals as a way to enforce community standards as opposed to jumping straight into enforcement. So it overall creates a more positive atmosphere and initial vibe.

As the eclipse foundation is an official non-profit organization, it likely wants to present a more polished and legally actionable code of conduct. This stands in contrast to Go, which appears to be focusing on the community angle. Therefore, the eclipse code of conduct reads less aspirational and with more specific guidelines that are likely there for legal reasons given the scope of the project.

Sugar Lab’s Code of Conduct

Sugar Lab’s code of conduct is based on the Ubuntu code of conduct. It reads as more of a narrative as if it were guiding the new contributor as they begin working on the project and giving them advice, as opposed to just stating the exact rules. It also focuses on one of its key missions of being a space for educators and emphasizes how it provides different forums for different levels. Overall, this code of conduct is both more practical as it gives out specific sections like “When you are unsure, ask for help” and has a softer enforcement language than Go’s code of conduct.

vLLMs-Ascend Code of Conduct

The code of conduct for vLLM focuses initially on standards for the community and lists specific examples of acceptable and unacceptable behavior which provides a detailed view for any new contributor. This choice makes a lot of sense when the next sections highlight how vLLM contributors work and communicate across communication platforms, as such these communication standards are relevant even in non-github platforms. As opposed to the previous conducts, vLLM’s code of conduct is the most explicit in terms of the stages of being warned to being permanently banned which also highlights how vLLM prioritizes community safety. vLLM’s code of conduct is also adapted from the contributor covenant which also illustrates why values and conduct are so central to vLLM’s code of conduct.

Read More

Week 1: Open Source

Thoughts on Open Source

When I hear the term open source, I always think of collaboration as anyone, regardless of their position or background can contribute to them. This does come with issues as these projects are only as good as the people that are currently maintaining them, and its difficult to continually incentivize great people to work on them as they could find more lucrative closed source opportunities. Also since its the internet, the low barrier to entry means that trolls and mis-aligned comments/commits can waste maintainers time and energy which hurts the longevity of the project. Even with these issues, some of the most important software in the world is and was open source, so it is still relevant even in a world where software is increasingly closed source. As such, I registered for this clan to learn more about how open source actually operates and to dive deeper into its history.

Open Source Projects that I have interacted with

My favorite open source project is a very simple one that is just a shared memory bank conflict visualizer that is useful when trying to optimize Cuda kernels. I use it fairly often and definitely inspired me to learn more about open source as I hope to also create useful software that others can use. I was also influenced by vLLM, SGLang, and CUTLASS as they provide high performance open source Cuda kernels that I learned alot from.

Read More