Open Source: Huge Benefits, But not without Risks

What are the benefits of open source software? It’s free. There is no vendor lock in. It’s free. It often contains very high quality code and it can be very flexible and easy to integrate. It might be backed by a large community of users that are willing to provide support, but mostly it’s seen as a tool to speed developer productivity. And, it’s free.

But when you agree to use open source code, it means that you’ve accepted any inherent risks that come along with doing that, and doing so isn’t risk free.

Some of the risks of using open source software include the following:

Security – While openness is a great benefit of Open Source software, it also means that the code is an open book for hackers to study and to find vulnerabilities in. And the popularity of many Open Source products mean that once a hacker finds a problem, the population of deployments using the flawed software might be very large. There is no guarantee that the software authors will ever correct known problems or vulnerabilities. Further, enterprises often don’t audit the contents of their software and don’t track updates and patches to the software components that they are using.

Licenses and Legal Issues – There are a few very frequently used open source licenses, but there are also a large number of non-standard licenses too. In all, there are more than 200 different open source licenses. The language of licenses can be difficult to understand and confusing. Using open source software on a project without fully understanding the implications, can put your business at legal risk.

Code Quality – Anyone can release open source code. There is no guarantee or warranty that the software can do what it says or that the code is written in a way that follows software best practices. It’s your responsibility to check out the quality of the code and to validate that it works as expected.

Sustainability – There are very many abandoned open source projects. The project developers may never have had the intent to maintain the software long term; there might only have been excitement in initially creating the project and publishing it. Using software components for the long-haul that aren’t being actively maintained may mean that when your product evolves or when versions of software dependencies change that the original open source component might break. In that case, either your staff needs to take over support of the software to make it useable or the software component needs to be replaced by a different solution, both of which can be costly and unexpected.