Don’t be a Turkey — 5 Common Mistakes Your Developers Make Using Open Source
Thanksgiving is upon us!
Filled with food, family, and hopefully some football — let’s go Seahawks — Thanksgiving is the time when families gather and talk about what they are thankful for.
Here at Mend, we are grateful for all the efforts that the open source community puts in to help others build innovative products faster, saving everyone time and money. Most of all though, we are appreciative of the developers who make it all happen. I’m talking about the guys and gals that work day and night to get the lines of code into your applications and websites.
Unfortunately, programming teams in today’s tech savvy world never get the proper recognition they deserve, often being overshadowed by the products that grab all the attention.
So this year, we express our gratitude to this rare breed of good talent for helping us evolve more innovatively into the future. You know who you are.
We also recognize that even the best will sometimes make stupid mistakes. Even with “smart” development environments that help to catch problems early, some issues will still slip through to gum up your team’s production.
In hopes of saving you from a little embarrassment this coming year, we have chosen to highlight the 5 most common mistakes your developers will make when using open source.
#1 Copy & paste open source code
Hands down, the most common mistake by open source developers is copying and pasting code and not noticing how much additional unwanted code they have just added in their environment.
Bill Sourour states that copying and pasting code snippets from sources like Google, Github, and StackOverflow is fine if you understand how they work. However, the same logic can’t be applied to open source code.
To prevent this common mistake, your developers should have a clear understanding of which code is needed when copying and pasting open source code into your application, and what should be kicked to the curb.
#2 Security all day everyday
When people think of using open source code, one of the first questions that comes to mind is, “if it’s open, how secure can it really be?”
While some people will argue that closed or commercial software looks more secure on paper, open source presents the wide-open door scenario. This means that more eyeballs going over the code from the community equals more security. By contrast, closed code is used in fewer projects but could have critical vulnerabilities that sit for long stretches of time unnoticed, waiting for a hacker to come and poke around to uncover the holes in their security.
When it comes to using open source, your developers need to understand the potential security risks in their code that can come with using libraries with known vulnerabilities. This also means knowing which bits of open source you have in your products and making sure that you are only using secure versions.
#3 Don’t forget to update
So you did your research and chose the most suitable open source component for your product.
Great. Now you have to make sure that it stays up to date.
Often new versions offer new functionality, fix reported software bugs / security vulnerabilities or add compatibility with other open source projects. These versions are the result of the open source community’s collaboration, working together to produce better code. But you can’t benefit from it without updating your versions. Beyond the “new and shiney” factor, new versions bring with them important fixes for security vulnerabilities, helping you to protect your product.
If you don’t update these versions, you expose your company to significant risk since hackers can see the same vulnerabilities and try to exploit them. All they have to do is look for newly posted vulnerabilities and try them out on organizations that are too slow to patch. The other threat is from hackers comparing the older version with the new one, picking out what was patched, and knowing exactly where to target.
Hacks happen, but don’t get exploited just because you failed to update.
#4 Am I allowed to use this license?
Using open source can really make your developers’ lives much easier, but also it can sometimes create a massive headache as well. This is especially true when it comes to your company’s legal team.
Another common mistake that developers tend to commonly experience is using an open source license that goes against your company’s policy. A classic example is the common GPL license that has created many legal issues for companies using this license in their components. One of the most annoying situations is where a developer takes a library with the GPL license and then only realizes it the end, shortly before the release. This creates a scramble to tear it out and replace it with code that is permissible according to your company’s policies.
Set clear policies about which licenses are allowed, and what is not. We suggest also having a system in place that gives you full visibility over which licenses are in your product, allowing you to quickly respond to questions from legal about whether or not you are in compliance.
#5 Dependencies
Last on the list but one of the more important mistakes concerns dependencies. Developers are usually oblivious to the number of open source libraries they are actually using due to dependencies. This issue is especially acute if they are using dependency management tools like Maven (Java), Bower (JavaScript), Bundler (Ruby), etc. that pulls in third-party dependencies automatically.
There are two main types of dependencies: direct and transitive. Direct dependencies are the libraries that your code is calling to and transitive dependencies are the libraries that your dependencies are linked to — basically, the dependencies of the dependencies.
Not tracking your open source dependencies leads you to lose visibility and control over your software. If your team is using open source, like almost any commercial software product in the market, then you must keep track of all open source libraries you are using, including direct and transitive dependencies.
Don’t be a turkey
We all want to be ninjas, but remember that a human can never really be “perfect” as there is always a margin of error.
The question is how well do we learn from our mistakes? What are the systems and tools that we put in place to keep mistakes to a minimum?
Hopefully this list will help you and your team focus as you pursue your development in the coming year, avoiding the pitfalls of the year before.
