Eric Raymond’s essay The Cathedral and the Bazaar proposes two modes of software development: the cathedral representing a top-down mode and the bazaar representing a bottom-up mode. When building cathedral-style, decisions are made by a few core contributors and limited to outside contribution. When building bazaar-style, a wide base of contributors work on a project. True in 1999 and still true today, both modes are practiced in successful projects.

Within the essay, Raymond also lists a few lessons on other software development practices. I’ve found the following relevant to working on open-source projects.

“When you lose interest in a program, your last duty to it is to hand it off to a competent successor.”

When evaluating projects to work on for this class, I considered a few open-source projects by Mitchell Hashimoto; namely, Ghostty. When evaluating other projects he’s worked on, I discovered that he had created a few Golang libraries that he now no longer maintains with a note linking to this GitHub gist post. In it, he explained that he no longer writes Go code and called for projects dependent on the libraries to fork them. Relating this to the Raymond’s lesson, Hashmoto blessed a few forks as recommended successors. Code decays, and by finding successors for his libraries, Hashimoto was able to extend the lifespan of his libraries and further benefit the open-source ecosystem.

“Given enough eyeballs, all bugs are shallow.”

Different programmers code differently. Between two programmers, they might use three different IDEs, four different languages, and five different programming-related tools. In the context of Gleam, the programming language my team is working on outside of class without many “eyeballs,” this means that a new user might be able to surface unencountered bugs or propose new feature requests. This was true in my case, when I noticed that the Gleam language server didn’t support hovering over types. When I code, I have a habit of doing this to double check proper typing, and so I created an issue and implemented the feature. As more programmers adopt Gleam, more users will report bugs and propose features like I did.

The Coffeehouse

In his talk titled The Cathedral, the Bazaar, and the Coffeehouse, Claude Warren builds upon Eric Raymon’s ideas on The Cathedral and The Bazaar by proposing a third form of software development: The Coffeehouse. Named after Lloyd’s coffeehouse where early merchants discussed and created the insurance on ships, the coffeehouse model proposes corporations creating Open Source Program Offices (OSPOs) as insurance on open-source projects. Through OSPOs, organizations can evaluate and support their open-source dependencies to prevent their collapses.

OSPOs

Some organizations today already have OSPOs. For example, Meta, creators of open-source projects like and Docusaurus, React, and PyTorch, has an open-source office for supporting its open-source projects. Additionally, Microsoft has an OSPO that on top of managing its open source projects, also has a fund its open-source dependencies (FOSS Fund). There also exists an OSPO Alliance that aims to help organizations start their own OSPOs.