Is it free or appears to be free? Regardless, it comes with its own set of challenges
According to Wikipedia, “Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose”. Simply put, you have access to the code and the freedom to modify, share and use it as you deem fit.
Traditionally software market has been closed source (proprietary) and primarily controlled by large organizations that released new versions of their product without sharing the underlying code. Organizations sell proprietary software with licensing rights and limited rights on anything else because it contains patents they own.
The Open Source Initiative was founded in February 1998 to evangelize open-source principles. As a steward of the Open Source Definition, it sets the foundation of the open-source ecosystem. OSS started gaining traction in the early 2000s, with computers becoming widely used to solve business problems and the internet becoming a sensation.
GitHub has played an essential role in being the defacto place for hosting open source projects. As of June 2022, it hosts over 28 million public repositories, showing the extent of OSS and its acceptance from the developer community. Large organizations like Microsoft, Meta, Google, Netflix, Uber etc., have released many open source projects for the benefit of the community at large, showing support and love towards OSS.
Who doesn’t love free lunches? An organization paying thousands of dollars yearly for a commercial license finds an equivalent OSS offering and is tempted to ask why pay when it is free? There’s nothing wrong with evaluating all the options before making an informed decision. As a software user, you should do a deep analysis before committing yourself to an offering. However, just because it is free to use does not make it a preferred choice. It would be best if you calculated the Total Cost of Ownership (TCO) here.
The most significant risk of OSS is that everyone associates it with being free. I am not against using OSS; on the contrary, I am a huge supporter of it. In my professional life, I have used numerous OSS projects that have made life easier and helped deliver value faster. To date, I go on GitHub to research trending projects and understand where the software industry is going. This article is to help change the mindset of software professionals to fully understand the implications of using OSS and whether their organization has an appetite for it or not.
Software development and deployment come with risks and assumptions. Organizations face multiple challenges while trying to adopt OSS. Some of the critical challenges are highlighted below.
Due to the open nature of code, it is more susceptible to security breaches. Yes, the licensed software can be equally prone to security issues; nevertheless, the open nature of code only aids the hackers. The recent log4j software vulnerability is a testament to the penetration of open source packages in both open & closed source software. The software community has comforted that OSS is more secure due to its transparency, and many eyes are watching to detect and resolve issues. In reality, some projects have too many and some too few eyes or none at all.
One of the exciting findings I recently heard was on an organization’s use of an OSS package to orchestrate workloads. The package is very popular and probably the defacto choice in most cases. However, the package was scanned for vulnerabilities by the organization before putting it into production. Surprisingly, many vulnerabilities were detected, which are still not closed by the maintainers of the package. The best part is that the organization is now looking at a managed service of the same software. It boils down to your risk appetite: Are you ready to ship a package with vulnerabilities in production, or do you want to spend the effort to fix them?
Deprecation and Updates
Software development is iterative, so the team periodically ships a new version. The same is true for OSS, where the maintainers would release a new version of their package/framework/software. The implication for the users of the package is to upgrade to the latest supported version, which might require updating your code, migrations, or anything else that requires a software professional to intervene.
Even though the old version would work as expected, getting any support or security patches from the maintainers would be impossible. Unless you are ready to take on the risk, it requires considerable effort to update your installation to the latest supported version several times a year. In a SaaS offering, the vendor updates the software with the process hidden away from the user.
Absence of Vendor Support
Putting a new piece of software is more than just deploying it to production. There are operations and support that are required to make sure it runs smoothly. You will undoubtedly hit roadblocks when you lift and shift open-source software to production without thinking about support or operations. Vendor support can be beneficial if it is to fix the severity one security issues, hitting performance issues, or just making sure you are using the feature correctly.
Organizations pay thousands of dollars yearly for support, making sure they can rely on someone to answer questions and provide best practices on use. No amount of documentation can be helpful when you hit issues in production. Community support for many projects is fantastic, but no SLAs are attached.
Running critical applications in production without support is undoubtedly not a good idea and can land you in hot water during disaster scenarios. Due to this, many OSS have now started offering managed services to provide the support that large organizations need to run their business effectively.
Learning Curve and Training
Most of the OSS come with excellent and rich documentation. However, it would be best if you had someone to spend time reading and finding the best practices for using it. You may be lucky and find someone with experience with the package who can share their learnings.
Compared to that, software vendors provide free training, developer advocates, and technical evangelization to use their software more. This training helps your workforce get certified and help them grow in their career. Additionally, they would keep you updated about the upcoming features, and if you are one of their large customers, you have a say in the direction of the software too.
Choosing an OSS or a vendor depends on your objective, team skills, organizational structure, security, and architecture. Once again, OSS is not free; the total cost of ownership may be more than the cost of buying the same service from a Vendor. When choosing an OSS, I look at it from the lens of the type of the project, whether it’s a framework, tool, or a full-blown suite, and then analyze it accordingly.
From my experience, many open-source frameworks are available to build your offering using those—start with looking at their license and suitability in your current ecosystem (tech & skills). These tend to be more popular and are generally backed by tech companies to build their products.
Full-scale open source offerings require much more scrutiny from a feature and supportability standpoint. This software solves a business or technical problem, and you need to host it in your infrastructure. Many creators of such software have started providing these as a SaaS offering to get started quickly and, at the same time, monetize it so that they can continue building more capability. This is a win-win for both the developers and users. Choosing to use the community edition or the enterprise edition is an entirely personal choice based on your needs. There are no wrong choices, just different choices based on your requirements and objectives.
“In real open source, you have the right to control your own destiny.” — Linus Torvalds