The promise of open source software – the free exchange of ideas, algorithms and code that is open and accessible – has been great for many companies. Using open source can significantly reduce technology investment, shorten delivery timelines and help eliminate vendor lock-in. It may have been naïve to think that having access to the source code will make programs less buggy; although this could be true, it’s not always the case and that could be a problem. However, I think as an industry we may have been lolled to sleep, dropped our guard or not paying attention, because one of the more used open source projects – OpenSSL – has had some rather scary issues. By now, we know it was just not the Heartbleed exploit.
One of my contentions with open source over the years was that the code base for many projects was huge and very few people could understand the project, build the project or actually do anything with the project besides use it as its stated purpose.
Take, for example, the awesome Eclipse project that is a standard Java Integrated Development Environment (IDE). It is much more; but just looking at the Java IDE in version 3.x there were 9,689 Java source files, which resulted in 1.9 million lines of code, and it continues to grow every single day.
The early proponents of open source would say: you have access to the code, you can find a bug and you can fix the code without having to wait for the vendor to fix it. This is technically true; but in reality, trying to fix a low-level bug in a huge software library would be outside most people’s ability. Remember, they are using this software (package) for a purpose, which is outside their day-to-day activities of building their own software.
That brings me back to the OpenSSL issue. Yes, it was open source and there are a ton of users using the library in their products. Heck, even the U.S. Department of Homeland Security and the U.S. Department of Defense have been associated with the project. The defect was introduced into the code December 31, 2011 and was not fixed until April 2014. During that time it is estimated that over 500,000 – thought to be secure Web servers, and certified with trusted authorities – were open to the exploits.
The point is that for over 28 months there was an exploit and it was in the wide open. People had the source; but if you don’t understand the code or have the experience or knowledge to understand how the code works, what does that matter? At this point, in that example, having the code is as useful as having the sentences from 5,000 books scrambled and you try to read them and make sense of what you are reading … which is not likely.
Therefore, we need to look at open source as a great tool; but companies using it must not be lolled into that false sense of security. In most cases, the exploit in OpenSSL could not have been fixed by an average developer; so the security blanket that was sold around open source is maybe not as true. Yes, you have the code, but you need to realize that you or your team are most likely not going to be able to fix the issue, and you will have to wait not on a company or vendor but on a community to fix and release the patch! Depending on the issue, since it is a community and many of the people working on the code are not paid, you could be exposed for a very long time.
Bear in mind that in 2008 a study was conducted that estimated that there were over 5,000 active open source projects in use at that time; but this is a fuzzy number and could be way off depending on the “license” being used to consider a project as open or not. Therefore, if you don’t think you are using an open source project, think again; the use of these projects is everywhere with every major vendor in the market today.
To try to illustrate the vastness of open source use, we can look at Oracle, one of the largest proprietary software vendors in the world. They support, run or control a vast array of various open source products. Some may be well known, others not: Berkely DB, Eclipse, EclipseLink, GlassFish, Hudson, Java.net, Jersey, Linux, Metro, MySQL, NetBeans, OpenJDK, VirtualBox and Xen. Just looking at MySQL, the numbers on use (which are old) show in 2004 there were well over 5,000,000 installations worldwide.
Can you imagine what would have happened if OpenSSL were owned or supplied by a commercial entity? Would there have been massive lawsuits against the company because it had flaws?
What is interesting is that most open source projects don’t have a real entity behind them, so it truly is use at your own risk because there is nobody to sue if things go wrong. Heck, maybe open source did not fail us after all because it continues to get fixed and there are no lawsuits claiming damage.
If there were an epic fail, that failure would fall on us, the people who use open source packages / libraries because we don’t think about the exposure it can bring to our organization. Because most of the time, it just works. We feel comfort that we have access to the source, and we feel comfort that our developers can handle almost anything. But the comfort is an illusion. As stated above, open source can be an unwieldy beast.
5 steps to ensure open source does not fail your organization
That is why I recommend that an open source review occur within the walls of your development shop / team. Take the following five steps so that open source does not fail you or your organization.
- Inventory all open source projects, libraries, packages / and products in use by your organization.
- Maintain a copy of all associated open source licenses used and file them with the legal department. If shipping the product outside into the wild, it is recommended that all license stipulations be reviewed and added to the release cycle to ensure compliance with said license stipulations.
- Designate an “Open Source Coordinator. This person is responsible for reviewing the inventory of open source usage and also keeping abreast of any issues within any of the packages being used. This will allow your organization to not be caught off guard because problem x, y or z was not reported outside the package’s project pages. It also increases communication between teams and makes them aware of patches, updates and other key information about the open source project being used.
- If you have multiple development teams, you may want to have a standing meeting to review new open source projects being proposed and added to your existing list. There are many times you can get duplicate functionality with different projects.
- Follow the rules. If the open source license requires publication of changes made to a package, make sure you publish the changes. You don’t need the hassle of someone coming out of the woodwork and claiming you are not following the license.
As a final thought, could this be a new way for companies to reduce risk / exposure? I can hear a vendor now saying, “Hey you can’t hold me or my company responsible because you have the source code since we made it available as open source and the license states use at your own risk.” Not exactly expected, but it is something to ponder.
Mike Rozlog’s 20-year software and technology industry experience brought him to dBase as the CEO to build the next-generation business intelligence products and data management tools. Mike is a dynamic leader known for driving innovation, product development, market analysis and product evangelism efforts. He has hands-on technical experience across architecture, enterprise and commercial software development. He is widely published and quoted in industry publications and is a frequent speaker at industry conferences. Contact him at firstname.lastname@example.org.