Open Source projects can be a great asset, or they can be a curse – it's all in how you manage it. To be successful in using open source, there are several things to keep in mind, from licensing to updates. And if you ignore any of them, it can cause problems.
Here are some things to consider.
What is the license?
There are a range of license options for an open source project, and components can range from free to use everywhere to very restrictive. It is important to have someone who is familiar with license types and who can set some guidelines on what is okay to use and what needs review. For example, are you okay with publishing changes or new code publicly because you used an open source component? https://opensource.org/licenses is a good resource to review common license types.Can’t hackers read the code and find vulnerabilities?
Absolutely, but you can do the same thing. Every Open Source component you decide to integrate into your products should be thoroughly reviewed for any security issues. There are tools that can scan the code, or you can use employee pretesting teams if you do not have the expertise in house.Are open source projects secure?
This all depends on the project. The first step I take in this area is to do a web search for any known vulnerabilities for the project. Next, I search the code check-ins and comments for the mention of security, vuln, vulnerability, etc. Even if these come up empty I still have a full audit done on the code for any undocumented issues. Checking other projects that the developers work on is a good idea, too. If the other code is full is issues, maybe no one has reported issues in this code yet.Isn’t open source full of bugs?
Maybe, but aren’t you going to test it? You must treat open source like any other code you integrate, whether it be from your engineers or contractors. Have a test plan in place, validate that the code works as expected and check for error handling. Does the code correctly log everything you would need to troubleshoot it?Will the developers provide me with support for the component?
This is a big "well it depends." Many but not all of the active projects have great forums or chat channels and use GIT to track questions and issues. These can be a great resource for support. There are even some with support packages you can buy to give you quicker response times. All of this is good, but make sure you have engineers who can read and understand the code. Don’t integrate a PERL component if none of your teams work with PERL on a normal basis.Do I need to stay on the latest version of the open source?
No, but you should check a new release for relevant security or defect fixes. It is a good idea to sign up for notifications on code changes and bug reports, too. Knowing that an issue exists even before a fix is available can help you protect your products and customers. Your engineers may even be able to mitigate the issue without the need for the latest version from the open source. Keep in mind that not all projects update version numbers when changes are made, so keeping track of changes and builds will keep you informed.Can I use a project that is abandoned?
Yes, but it could have some risks depending on the function of the code. Some of the abandon projects are not abandoned but have just reached maturity and do not need updates. For example, code that validates a phone number doesn’t need to evolve until we add new area codes or change the number of digits in the number. If the code needs to evolve and it uses encryption, then it needs to be updated to use the latest secure ciphers, and the insecure ones should be removed.Are there any best practices when looking at an Open Source project?
Yes, everyone has their own list. Here are some of the questions I ask when evaluating an open source project:Image
