Reflect on “Why should you have an Open Source Program Office?”

In this video, the two speakers are Nithya Ruff, Executive Director of the Open Source Program Office of Comcast and chair of the board of the Linux Foundation, and Gil Yehuda, Head of Open Source Engineering and Technology at U.S. Bank. They shared a lot about the importance of the Open Source Program Office in their companies. In the beginning, the host Dave asked them a question, why their companies need an Open Source Program Office, as they are not some tech company. In Gil’s response, he mentioned that nowadays banks also have a lot of digital data, such as money and transactions, so in some ways bank is also a tech company and they need an Open Source Program Office. His response is not really convincing to me, because if we consider a bank as some sort of company because they also have digital data, this only proves that they need an IT Support department, this cannot prove that they need an Open Source Program Office. But for most of this video, his ideas are very interesting, especially when he mentioned that “Open Source forces engineers to do better”, as engineers knew that their code would be an Open Source project, they started to write better documentation, unit tests and comments :). Also, I agree with his idea that Open Source allows making engineers better, as they are both humble enough to accept issues and PRs and also bold enough to share their code, even if it is imperfect.

When the host Dave asked the speakers about their opinion of the cost and benefit of open source, he defined the time spent on documentation as a cost, and Gil thought that we should reconsider this from the overall cost, if there is no documentation, it will be much harder for future developers to understand and maintain these code. I agree with this and this reminds me of the concept of technical debt from Ward Cunningham. In this concept, some problems with code are like financial debt, as you can borrow against the future, but you still need to pay it off, such as the maintenance issues or hidden bugs. However, I think if we have more formal and standardized documentation, it will be much easier to maintain in the future.

I think in this talk, speakers gave me ideas about how Open Source acts in industry. I feel that in the industry, we have to face much more practical problems, such as Legal problems, as Gil mentioned if they want to make something Open Source or Open Data in banks, this must be secure and stable as banks and finance are a more regulated area, these actions must be approved before processing. Also when Open Source Programs were first in the Legal department in many companies. This also reminds me of the guest talk from Gil recently. When I asked him a question about the difference between Open Source in the industry and individual developers, he said that in the industry, companies will consider it more comprehensively, such as the financial benefit. Here is my understanding: as in the industry, it cannot be as free as individual developers, their actions are more regulated and practical, but this regulation is also a guarantee that they can continue and survive in the future, they need these kinds of support from the company and industry.

Progress on Group Project

A big challenge so far is maintainers respond to our issues and PRs very untimely, for the first two PRs from our team, they responded after a week that we made the comments that we would like to work on that, also these two PRs are still not merged, it is still pending to be reviewed for over a week. So now we are still working on other bugs while waiting for the maintainers to merge the PRs.

Another surprising and interesting thing is I found a proposal about new Document about License and Usage from p5.js 2.0, which has a connection to the legal issues in Open Source covered in the video “Why should you have an Open Source Program Office?” and Gil’s guest talk. In this issue, a developer mentioned that it is unclear for artists and developers if they want to use p5.js in various contexts. I think this proposal is more likely for users as artists, if they want to use p5.js to create some artwork, it might be unclear in the documentation about using their artwork for business.