As my final semester at NYU draws to a close, I find myself reminiscing about the incredible experiences I’ve had throughout my academic journey. This blog post marks the end of a chapter, but it is certainly not the end of my personal journey or my contributions to the world of open source software.

Looking back on this class dedicated to open source, I can confidently say that it exceeded my expectations. While I wasn’t entirely sure what to anticipate, I am leaving feeling thoroughly satisfied and happy with the knowledge and skills I’ve gained. It has been a fitting culmination to my run at NYU.

When you hear “open source”, you likely think of things like Linux, Wikipedia, or Firefox - community-driven software projects where the code is openly shared and collaboratively developed. Atleast, those are some projects that come to my mind first. However, the open source philosophy of transparency, community involvement, and free sharing of information is being applied well beyond just software. A wide range of projects across various domains are embracing open source ideals to drive innovation and democratize access to knowledge and resources.

One fascinating example is Open Source Sports (OSS), a platform dedicated to crowdsourcing the best rules and formats for sports and competitive events. OSS involves a diverse team of developers, athletes, enthusiasts and more working together to refine the rulesets for both official sports like the UFC and NFL as well as novel, community-created games. The open nature allows for rapid iteration and incorporating a multitude of perspectives.

Lessons from The Cathedral and the Bazaar Revisited

In our recent class discussions about Eric Raymond’s influential essay The Cathedral and the Bazaar, we explored the contrasting development models it describes: the traditional, centralized “cathedral” approach versus the decentralized, open “bazaar” approach. Each student shared their favorite lesson from the essay, and the diverse perspectives offered new insights.

A couple of quotes that really resonated with me were “Good programmers know what to write. Great ones know what to rewrite (and reuse),” and “Every good work of software starts by scratching a developer’s personal itch.” The first highlights the importance of leveraging existing code and not reinventing the wheel - wisdom that the open source world embraces wholeheartedly. The second quote reminded me about how I have a running list of problems, annoyances, or interesting ideas that catch my attention in daily life. When contemplating potential projects, referring back to that personal “itch” list has generated much more engaging and meaningful concepts than just trying to think of ideas from scratch.

In his recent presentation, Christopher Snider from Tidepool highlighted how their nonprofit is leveraging open source software to create innovative diabetes management solutions to reduce the burden of Type 1 Diabetes. Their flagship product, Tidepool Loop, is an FDA-approved app that connects insulin pumps and continuous glucose monitors to provide automated insulin delivery.

What makes Tidepool Loop truly groundbreaking is that it is built entirely on open source software and standards. This open approach stands in stark contrast to the traditional model in healthcare, where proprietary systems lead to data silos and lack of interoperability. The open nature of Tidepool’s work facilitates external contributions, rigorous peer review, and trust through transparency. Clinicians, researchers, and even patients themselves can inspect the Loop codebase, suggest improvements, and be confident about its safety and efficacy. This flexibility and choice is revolutionary in an industry that has long been dominated by closed systems.

The use of open source technologies is no longer confined to the software development world. As evidenced by several insightful videos, open source principles and practices are being embraced by diverse industries for driving innovation and transformation.

One area where open source is gaining traction is within large enterprises through the innersourcing model. The video “How InnerSource can accelerate culture change” highlights how innersourcing brings the collaborative mindset and transparency of open source development inside a company. By treating internal software projects as open source with open contribution and code sharing, innersourcing breaks down organizational silos and fosters a more empowered engineering culture. Companies like PayPal have used innersourcing to scale best practices and accelerate delivery of high-quality products and services.

As data becomes increasingly central to so many fields, having robust tools for data manipulation and analysis is crucial. That’s where the pandas library comes in - a powerful, open-source Python library that has become a staple for working with structured data.

With its intuitive data structures like Series and DataFrames, plus a rich ecosystem of input/output functionality and data processing tools, pandas makes wrestling with messy datasets a breeze. It’s no wonder pandas has exploded in popularity and is now deeply embedded into the Python data science stack.

I was recently watching a video on “How InnerSource can accelerate culture change” that really got me thinking about the often overlooked challenges of maintaining open source software projects. What exactly is the work that open source maintainers have to shoulder? Why does this crucial role frequently get overshadowed?

From browsers and operating systems to data science libraries and cloud infrastructure, crucial chunks of code that power our tech ecosystem are created and maintained by communities of developers contributing their time and expertise. However, as open source has become embedded into nearly every facet of technology, a major issue has emerged - the maintainers who keep these critical projects viable are overworked, underpaid, and often underappreciated for the immense effort they put in.

How exactly does the software you use daily get created? There are two contrasting philosophies at play, often referred to as “the cathedral” versus “the bazaar.”

The Cathedral Model

For decades, software was built using the cathedral model - small, isolated teams of developers meticulously crafting code through rigid, pre-defined processes. It was a closed-off, hierarchical system akin to how medieval cathedral builders painstakingly constructed those grand edifices over generations.

FOSS innovators

This week in my open source software class, we researched the backgrounds and bios of some of the most influential people in the history of the free/open source software movement. Reading about pioneers like Richard Stallman, Linus Torvalds, Guido van Rossum, and Tim Berners-Lee was eye-opening.

I was struck by how the origins of free and open source software were driven by a combination of brilliant minds who cared deeply about principles like freedom, collaboration, and access to knowledge. At the same time, they were rebels who bucked against the increasing corporatization and proprietary lock-in of software in the 1970s and 80s.

I recently spent time evaluating open source projects so I can jump deeper into one of them! Assessing the fit requires looking at multiple factors - how active is the community? How quickly do maintainers respond? Are there approachable issues for newcomers? After this analysis, I could tell which projects were a better fit for me. I’m excited to immerse myself and see where it leads!

Exploring Options

I explored the Godot game engine, which my friend raved about. The vision seems really impressive and I’d love to contribute. However, their open issues require more specialized knowledge in the game development field than I have. But who knows, it seems so interesting that I might still take a shot at it one day!

I was genuinely amazed after watching the videos “Opening the Loop” and “Healthcare Made Human” this week. These videos spotlight open source projects in the healthcare industry aiming to help people with diabetes. It saddened me to see the daily struggles many face simply to get access to the insulin they need to survive. However, the power of open source collaboration also shined through.

OpenAPS especially intrigued me - it connects continuous glucose monitors to personal devices so patients can set customized alarms and notifications. By tapping into an existing tool and making it more personalized and reactive to individual needs, OpenAPS empowers patients to better control their treatment. The potential here is exciting.

My team recently published our very first Firefox extension: insult reminders, that I started talking about in last week’s post, to the Firefox Add-On Store. I ended up working on all parts of the extension over time. This included writing functionality in JavaScript, styling elements with CSS, building out HTML components, handling the publication process, and finally including components to make the project open-source.

Creating my first browser extension pushed me outside my JavaScript comfort zone, as I had to apply the language in entirely new contexts to enable browser modification. I also started using console logging to debug issues! Persistently fixing bugs piece by piece was extremely rewarding.

I’m excited to share my journey on my very first open source project - a Firefox extension called Insult Reminders. This idea stemmed from my personal affinity for productivity timers, but feeling I could use an extra dose of motivation when I inevitably hit snooze.

The Concept: Mixing Productivity with Playful Humor

Insult Reminders provides configurable timers for tasks or breaks. But if you choose to snooze when the alarm goes off, get ready for some hilarious insults lobbed your way! The idea is to add a touch of humor while also incentivizing actually sticking to routines. I thought others might like the friendly push from some funny insults to keep them on track with their plans.

Open source communities are diverse, distributed, and at times disorganized - often spanning dozens of countries and hundreds if not thousands of people. Like any other human communities, issues can arise without clear guidelines around expected behavior and acceptable interactions. That’s where codes of conduct come into play for open source projects.

Codes of conduct set clear expectations for behavior and help ensure all contributors feel safe and welcome to participate. Without them, projects can become breeding grounds for discrimination, harassment, and other toxic dynamics that drive people away. By establishing shared guidelines upfront, codes of conduct empower communities to have productive dialogue to resolve conflicts and develop strong norms.

Prior to this class, I had heard the term “open source” used to describe some software projects and meddled in some projects myself. But if I’m being honest, I didn’t know all the ins and outs. I’ve since learned that open source has some very clear principles - it should be available for anyone to access, read, modify, and distribute. The openness allows for collaborations between developers tackling common problems. Pretty amazing!

As I’ve been learning more about open source, I’ve started to see more advantages. Firstly, there is code transparency as we can see what’s happening behind the scenes. Since anyone can contribute, high quality software can be produced as numerous different minds are working on it, leading to faster innovation. On the other hand, closed source does allow companies to keep proprietary information confidential and make profit from their products. Hence, there are pros and cons to both approaches.