Open Source has been in commercial usage since the 1970s, but sometimes the picture painted by the media tends to be superficial and simplistic. For anyone developing software professionally, all this open-source hype no doubt seems pretty farfetched. So let’s take a closer look at the top 10 open source myths and try to clear up some misconceptions which I regularly encounter.
Myth 1: Open Source and Free Software Are the Same
Free software is not necessarily open source and vice versa.
Commercial software, that is given away for free, is not open source software unless it was given an open source license. If it was only given for free, then you can only use it for your own purposes, but you do not have the right to modify and redistribute it like open source software.
There are (too many) projects on GitHib without an open source license and, therefore, these projects are public, but they are not open source and commercial software companies do not have the right to use, modify and/or redistribute it. The absence of a license means that the default copyright laws apply. This means that the author retains all rights to their source code and that nobody else may reproduce, distribute, or create derivative works from it.
Myth 2: Open Source Is Only about Saving Money
Yes, open source is free, and while it is a major benefit, it’s not the only reason for choosing to use open source. Every engineering manager wants better productivity and better quality. Open source supports both these goals. It increases your team’s productivity as they don’t need to waste time reinventing the wheel.
Besides, the open source components you are using are being used by many other developers around the world. All those capable hands are working together to identify, and usually quickly fix security and quality issues in the code. Many believe that due to this reason open source is becoming safer than proprietary code as the open source community grows.
Myth 3: Using Open Source Is Like Walking Into a Legal Minefield
Open source components are free to use, but they come with a license that you have to comply with to avoid legal and business risks. As long as you comply with the terms and conditions of any licenses of the components you’re using, there’s no risk in using open source.
There are roughly 70 open source licenses acknowledged by the OSI, so understanding how to use them correctly is not an easy task for companies without dedicated legal teams. In this case, it’s far better to create a white list of open source licenses you allow your developers to use, rather than veto all usage of open source.
Remember that there are many ‘commercial’ friendly common open source licenses, like MIT, BSD, and Apache. If you’re interested in creating a blacklist of licenses (not permitting specific licenses) to widen your developers’ choices you can do that by setting up automated policies with an automated open source management tool like Mend. Remember that open source offers you many benefits, but it also comes with responsibility.
Myth 4: Open Source Has No Restrictions on Patents
Software is unique because it can be protected by both copyrights and patents. Copyrights in software protect the unique expression in the code while patents protect new and innovative functionality. So you copyright the code and patent the function. Patents are far more valuable for that reason given that a patent would protect the implementation regardless of how the code is written or what languages are used.
Open source describes a broad range of software licenses that make source code available to the general public with relaxed or non-existent copyright restrictions. However, most permissive open source licenses grant copyright to users, but not patents.
If you are planning on patenting your functionality, then you need to ensure you are using the right license that will enable you to do so. Most permissive open source licenses are more restrictive that what you think.
Myth 5: Open Source Development Is Done by Amateurs and Students
When most people think of open source developers, the stereotype that comes to their mind is a junior code developer that does it at home, at night, as a hobby.
Over the past two decades, open source development has come to be seen as a key to driving innovation. Even companies that once saw open source as a threat have come around — Microsoft, for example, is now active in numerous open source initiatives.
The biggest communities driving open source today are actually software enterprises through various foundations like OpenPOWER (a collaboration of IBM, Google, Mellanox, Tyan and NVIDIA), Linux, Open Virtualization Alliance (OVA), OpenStack and more.
Myth 6: The Security and Quality of Open Source Code Is Not as Good as That of Proprietary Software
This should not be surprising for you if you’ve read some of our previous posts; we strongly believe that open source can be safer than commercial software.
The reason is, unlike your proprietary code, you are working on the same code with hundreds (if not more) other capable software developers and when it comes to both security and quality, the more sets of eyes you have on your code the more likely you are to find issues.
Another important fact is that open source security and quality issues are fixed faster, once discovered, so it is easier to fix your code by implementing a patch or a new version.
Myth 7: Big Software Companies Don’t Use Open Source
This myth should be a thing of the past. Corporate use of open source is pervasive and, according the 2015 open source survey, over 66% of all companies consider open source options first and only then other alternatives. All companies from all sizes are using more and contributing more to the open source community.
Myth 8: Open Source Doesn’t Play Well With Proprietary Code
Open source is not a competitor to proprietary code. It was never meant to be. Commercial software companies are complimenting their proprietary code with open source code to avoid investing resources on code that is not unique or innovating.
Besides productivity, there are other reasons as well to consider open source and proprietary code as complimentary. One reason that comes to mind is that open source will let you develop relationships with other software packages. Another reason might be that you would like to enable your users to customize certain aspects of your solution.
Myth 9: Tracking Your Open Source Inventory Is Easy
The problem with manual reporting is that it depends on perfect compliance, and we know we don’t always get everything right. That’s particularly true on development projects, especially when you’re trying to move faster than ever and when you’re trying to innovate.
But even if things do not slip away, and we are able to ensure our entire team is managing our inventory lists perfectly, every open source components has many dependencies and it requires a lot of efforts to create a complete list of all dependencies of each component manually. It’s much easier to have a machine do it for you by scanning the software code automatically.
Myth 10: The Only Solution to Get an Accurate Inventory Report Is to Scan My Code
Code scanning is the traditional solution to get accurate reports about the open source code in your software. But, this technology takes a lot of time and resources. There is a far better alternative today in the market that is able to give you accurate information effortlessly.
Mend.io offers a disruptive new technology that supports you throughout your software lifecycle process (from development to release) and provides real-time alerts and comprehensive reports (inventory, licenses, security and more). All that without ever scanning your code.
Mend.io becomes part of your build process and automatically identifies open source components in minutes, every time you run your build. It also provides real-time alerts if you happen to add a problematic license or if you are using a component with a known security vulnerability. Traditional code-scanning is no longer the optimal solution for commercial companies looking to get a better control over their open source usage.
