The Cathedral and the Bazaar - Lesson from Oppia

Eric Raymond’s essay “The Cathedral and the Bazaar” provides valuable insights into different software development models. As I’ve worked with the Oppia project with our team (Oppia-3), I’ve experienced several of these principles firsthand:

“Release early, release often”

This principle resonated deeply with me through a relevant experience. I identified a simple UI front-end issue that could be improved and posted a feature request. Being new to the community, I wasn’t familiar with the contribution process. When I checked back a day later, after reviewing the contributing guide, someone had already commented that they wanted to be assigned to this issue. I initially thought I’d missed my opportunity but then discovered that the admin required actual implementation work - the person needed to complete the improvement in their local environment and record a video showing the fix before being permitted to submit a pull request. This taught me the importance of early and frequent engagement - waiting even a day can change opportunities.

“Treating your users as co-developers”

I experienced this when I emailed Oppia’s main admin, Sean Lip, with a basic question about contribution opportunities based on my current skills. I honestly didn’t expect a response since my inquiry wasn’t coding-related, but Sean quickly replied and suggested I could help with translations. This friendly and inclusive approach demonstrated how Oppia treats even potential contributors as valuable community members, regardless of their technical background. The community’s supportive nature makes it welcoming for newcomers like me to get involved.

The Coffeehouse Idea by Claude Warren

At DevWorld 2024, Claude Warren from the Apache Software Foundation presented “The Cathedral, the Bazaar, and the Coffeehouse,” which added a new dimension to Raymond’s original concepts. The Coffeehouse represents an environment where:

• People freely gather to exchange ideas and inspire creativity
• It functions as an open platform for intellectual exchange
• Contributors from diverse backgrounds can all participate

Warren’s presentation suggested that OSPOs (Open-Source Program Offices) and interested parties could create coffeehouse-like environments where they:

• Share data about open-source projects
• Select metrics for evaluation
• Publish reports on common projects

This collaborative approach mirrors what I’ve experienced in the Oppia community - an open space where diverse contributors come together around shared goals while maintaining individual perspectives and expertise.

The Role of OSPOs in Companies

Open Source Program Offices play crucial roles in organizations that rely on open-source software. Based on my participation in the NYU BUGSxAWSxPython Software Foundation discussion panel in this early semester, I learned about OSPOs in companies like AWS:

AWS OSPO’s Key Functions:

• Strategic integration of open-source into AWS services while ensuring compliance with licenses
• Supporting developer communities through sponsorships and direct contributions
• Guiding internal teams on best practices for open-source engagement

Another company I’d like to discuss is VMware.

VMware’s Approach to OSPOs:

• Facilitating internal contributions to open-source by simplifying approval processes
• Managing potential intellectual property risks while maximizing innovation benefits
• Training developers on effective participation in open-source ecosystems

These companies recognize that open-source software is not just about using free software but creating strategic partnerships with communities that drive innovation. By establishing formal OSPOs, they ensure their open-source interactions are both beneficial to the company and sustainable for the wider community with a systematic guideline.

My experience with Oppia has given me a glimpse into how these principles work in practice, as I continue to explore translation contributions and potentially coding-related tasks in the coming weeks! :)