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.