Week 9: The Cathedral and The Bazaar & Learning about how and why large companies contribute to open source v2
This week we both discussed lessons from Eric S. Raymond’s “The Cathedral and the Bazaar” and we also had Gil Yehuda who is the Sr. Director of Technology Strategy at Open Source Program Office at Yahoo as our guest speaker. I want to start with “The Cathedral and the Bazaar” and discuss Gil Yehuda’s presentation next. Finally, I want to mention our group project progress.
The Cathedral and The Bazaar by Eric S. Raymond
The Cathedral and the Bazaar by Eric Steven Raymond was an eye-opening essay for me. I have been using various open source tools, and I have never thought about their development from Eric Steven Raymond’s point of view. I think his views even apply to private companies and their proprietary projects.
The first part of the essay is quite universal. The idea of developing a project like a cathedral or a bazaar can be applied to many situations. Of course, in the context of open source software, this refers to software versions, but this can be applied to the hardware industry as well. For example, some tech companies prefer to release finished and debugged products every other year while some of them release products every six months.
Release early. Release often. And listen to your customers.
Taken from Eric S. Raymond’s “The Cathedral and the Bazaar”
Of course, both the cathedral and the bazaar approach have their own advantages and disadvantages. I personally believe that the bazaar approach should be used where possible. For example, as we discussed in class, the bazaar model wouldn’t make sense for a washing machine because no one wants to buy a washing machine that doesn’t always work. Applying patches to a washing machine would also be challenging. That being said, I think the bazaar model makes a lot of sense for an operating system for a personal computer.
The bazaar model enables developers to get frequent feedback from the users. I believe receiving feedback frequently is important because users can detect the bugs early, and this can save a lot of time. Additionally, users can give feedback on the general user experience for the product and the developers can change things before it is too late. The cartoon below doesn’t aim to explain this issue, but I think it can also be used to explain it.
The other quote from the essay I want to emphasize is the following:
Every good work of software starts by scratching a developer’s personal itch.
Taken from Eric S. Raymond’s “The Cathedral and the Bazaar”
I think people do work more efficiently and willingly if they are trying to solve their own problems. Yes, there are many people that are coding for projects that they are no interested in to make a living. However, people do take more care and spend more time if the project is somehow related to them. A project is like a baby; it takes time and a lot of effort to grow it. If the core developer doesn’t like the project from the beginning, he/she might want to spend their time on other more interesting projects. Therefore, I agree with this quote, and I believe every good work of software starts by scratching a developer’s personal itch.
Learning about how and why large companies contribute to open source v2
Gil Yehuda’s presentation was touching on interesting points that Kevin P. Fleming didn’t mention during his presentation, see week 5 post. I realized that Yahoo is more focused on developing their own open source projects while Bloomberg is focused on contributing to existing open source projects. Both of these companies contribute to open source, but in different ways.
I think another highlight from Gil Yehuda’s presentation was about using open source projects to extend other open source projects. For example, if an open source project is designed for working only on a single computer, we can create a version of it that can run on multiple computers using an open source project designed to make distributed computations. This would make both sides happy since one side gets a new usage area, and the other side gets a new feature. This is something that I would keep in my mind when I decide to work on an open source project in the future.
Gil Yehuda also mentioned the employment aspects of the open source. He emphasized that it is possible to get paid to work on the open source project. I think it is a dream job for me. This class introduced me to the open source world, and I loved it. Contributing to open source as a daily job that makes me a living, sounds amazing.
Group project progress
This week we had a sudden u-turn in our decision to contribute to Jupyter Interactive Notebook. Instead of contributing to Jupyter Interactive Notebook, we decided to contribute to JupyterLab. It is not a big change in our decision that we are still planning to contribute to Jupyter. However, we changed our minds to contribute to another Jupyter project. JupyterLab is the upcoming version of the Jupyter Interactive Notebook. Jupyter decided to lunch a completely new project other than keep patching the Jupyter Interactive Notebook. I think our decision makes sense because there are a lot of new issues and bugs in the JupyterLab project. However, there are not many bugs in the Jupyter Interactive Notebook project because it is a very old project, and almost everything is fixed so far.
Jupyter community members are spending their time on actively developing the JupyterLab project, and the JupyterLab community is very vibrant because of this. Most of the “first-good-issue” tags are only a month old in the JupyterLab’s GitHub repository. However, most of the “first-good-issue” tags are two years old in the Jupyter Interactive Notebook’s GitHub repository.
We have even introduced ourselves to the community and claimed our first to work on, see issue #8094. We even received a welcome message 3 minutes after we posted our introduction message. Definitely, the community is very active, and I think the activeness of the community will benefit us.