According to Hila Fish, the benefits of open source projects are supporting rapid innovation, the flexibility provided to customize and adapt tools, and transparency of the code which can enhance security efforts. The downsides are that security by obscurity doesn’t apply, open source is potentially prone to abuse, and when open source tools are not backed up by companies, it might result in a lower level of maintainability.
Hila Fish spoke about the DevOps perspective on open source at DEV: Challenge Accepted 2023.
Open source projects often have a faster pace of innovation due to their open nature, Fish said. DevOps teams can tap into this rapid innovation cycle to adopt new technologies and practices that improve their processes. Fish mentioned areas like continuous integration, continuous delivery (CI/CD), containerization, and infrastructure as code (IaC), where open source tools and solutions have driven innovation in the DevOps space.
One of the core principles of DevOps is the ability to tailor processes and tools to the unique needs of an organization, as Fish explained:
Open source software provides the flexibility required to customize and adapt tools to fit specific workflows and requirements. DevOps teams can modify, extend, and integrate open source solutions to create an optimized toolchain, she added.
Open source projects emphasize transparency by allowing anyone to review the source code. This can enhance security efforts within the software development cycle, as teams have the opportunity to inspect code for vulnerabilities and make necessary improvements, Fish said. The collaborative nature of open source often leads to swift responses to security and various other issues, helping DevOps teams maintain a secure and stable environment.
There are also a couple of downsides to open source projects. Fish mentioned that the notion of "security by obscurity" doesn’t apply to open source tools. Proprietary software companies can claim their code is more secure than open source alternatives because of that, and that it’ll be harder for hackers to exploit loopholes since the code is not publicly available, Fish said.
Fish also mentioned that open source is potentially prone to abuse:
There were recent cases like "Colors" NPM package and "FakerJS" where the maintainer sabotaged/deleted the project, each for their own reasons, which is something we need to know that has the potential of happening (even if not happening a lot) while introducing open source tools to our environment.
A lot of open source tools are not backed up by companies, Fish said. As the maintainers are individuals, they can decide they discontinue the maintenance of these projects:
If we integrate these types of projects, it’ll mean we will either need to maintain it ourselves, or migrate to another well-maintained tool.
Fish mentioned that with open source you need to "assume good faith". If you have an open source tool in production, and it has a bug, and you opened an issue to have it fixed, it could potentially take months, if not longer, for the bug to get fixed as they don’t owe us anything.
Yes, you could open the code and try to fix it yourself, but not all of us have the resources to do that, so we rely on the project maintainers to fix it for us.
Fish suggested explaining the issue and its urgency. People might be able to help faster as most if not all open source maintainers are all about collaboration and communication, as this is the essence of open source culture, she said.
Fish suggested doing research before integrating an open source tool into the environment, especially the production environment, to make sure that it is well maintained in case of issues that will surely arise.
InfoQ interviewed Hila Fish about working with open source tools.
InfoQ: What criteria do you use to select open source projects?
Hila Fish: I take eight key metrics into consideration: popularity of the project, level of activity, security, readiness, documentation, ecosystem, ease of use, and roadmap. Each key metric has sub-questions you can ask and find the answers to, which will allow you to assess the project maturity level in each of those key metrics.
InfoQ: How do you use those criteria?
Fish: To give an example, one of those metrics, level of activity, will help you roughly estimate how long you should wait for a bug fix/feature to get released in the open source project. Checking if the commits rate is daily/weekly/monthly, the number of issues, and the number of releases could give you a good understanding of the activity level.
Documentation is another important metric in selecting open source projects. Documentation is the gateway for that project, and if it’s rich it covers most aspects like how to integrate, known issues, features explanations, etc. With documentation, you can make a much more educated decision about whether to adopt this tool or not.