Part 1 - The Cathedral and the Bazaar

Eric Raymond’s essay provides some very interesting insights about the early days of Linux and how it changed his (and probably a lot of people’s) ideas about open source development. Reading it several decades later, many of the topics he brings up are still relevant in my experience with open source.

The first thing that stood out about Raymond’s essay was the idea of the bazaar and how he wrote about it more or less as an absolute positive. In many ways, he is correct - having such open, community driven development makes things much faster and encourages people of different skillsets to get involved. However, there are certain safeguards that should be in place with this style of development to ensure that it remains a positive experience. For example, in working on my group project, for which we chose to contribute to the open source YC backed startup Preswald, they heavily prioritize development speed, sometimes at the expense of their contributors’ experience with the project. Claiming issues is a very loose process and it is not uncommon for an issue that has been claimed to be silently picked up by another user who submits code without any prior acknowledgement and has their work merged, taking it out from under the original assignee. This free for all format is great for the project, as it allows things to move as fast as people can write code, but can lead to frustrations that a more structured, cathedral approach could avoid.

Despite these gripes, I will admit that the bazaar format and the “release early and often” ideology are great for young projects, facilitating rapid growth and allowing for the community to give input on features as they are developed rather than having dark patches followed by massive, potentially unpopular changes. Through working on Preswald I have seen this first hand, with the project exploding in size over only a few weeks and gaining significantly more functionality than what was there when we first researched it. It is undeniable that this growth is a result of open sourcing the project and constantly merging contributors’ code, as the three maintainers would not be able to develop the project at a comparable speed. Raymond notes that Linux “seemed to go from strength to strength at a speed barely imaginable to cathedral-builders,” and I see the same happening as I work on Preswald, as people from all different backgrounds are able to contribute their expertise and grow the project at a rapid level.

Part 2 - The Coffeehouse

Clause Warren’s talk adds the idea of the coffeehouse to the cathedral and bazaar concept, which is essentially a collaborative space for parties with similar interests to discuss their work and share data and ideas. He focuses heavily on the fact that projects that are reliant on open source often become a giant web of dependencies where if one fails or is abandoned it can be very difficult to get everything else back online, and that it is therefore important to have insurance against this type of situation. For large companies using open source in their codebase, this means creating an OSPO to serve as a middleman between their internal team and the communities of the open source projects that they use, investing in open source to prepare for the possibility that a project could eventually stop support and put their internal products in jeapordy. The OPSO would have a team of experts on the open source projects the company uses and be able to support the internal team, benefiting both the company who gets protection against open source getting abandoned and the open source community who gain major contributors with vested interest in the project. For example, Amazon is a major contributor to open source projects that they use such as PostgreSQL and Rust, and are also significant donors to groups such as Cloud Native Computing Foundation, which helps them ensure that the projects they use continue to grow and improve, in turn improving their own products. A coffeehouse would include these OSPOs and anyone else with interest in these open source projects and would act as a way for them to report their findings and work amongst each other to further insure their products’ security against some upstream dependency failing.