open source

Did Open Source Software Fail Us?

  • author image

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,, 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. 

  1. Inventory all open source projects, libraries, packages / and products in use by your organization.
  2. 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.
  3. 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. 
  4. 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. 
  5. 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 







By Shane Curcuru

Good points for any organization, however even that breadth of examples discounts the many bits of open source projects – many run by legal foundations, like Eclipse or Apache – that are prevalent just about everywhere you look on any computer. You certainly do need to know within a business where you are using these bits, just as you’d normally want to know what bits of proprietary software you’re using. Certainly there are issues with some projects, but on the other hand – how much of the internet would actually work without the many freely open source products that are out there?

An exercise for the reader is to ponder the number of different specific open source projects that you are using right now to read this page – or the author is using to serve this content from their web server. Luckily, they work quite well most of the time!

By Mike Rozlog

Hello Shane,

You are correct, a vast majority of Open Source projects/products work very well and yes you are 100% correct about how much is being used. That was one of the main points, how much Open Source do you have in your organization? What are your guidelines for adding new Open Source projects/products, if you have any? Are there any legal exposures that come with using specific projects / products? How are you as an organization watching or monitoring the list to see if there are exploits that you should be aware of? Then finally, the point of “fixing” a broken project / product, is usually (not always) overwhelming to any organization. As an example, there is an exploit in Apache Web Server; could you or anybody on your team reliably fix it or is your organization reliant on the community at large for the fix and what type of exposure does that give your organization?

Again, not saying anything against Open Source, but more trying to raise the responsibilities that get glossed over because most used Open Source projects / products just work.


By Frank Hunt


Shane’s above statement “they usually work quite well” is not necessarily reassuring. Are you aware of any corporate IT project/system failures that can be linked to the use of Open Source software?

By Michael Rozlog


Heart-bleed was one and it did cause issues for a lot of companies. However, most companies keep this information to themselves; they don’t want to publicize any known exploits. That is why I think it is important to have a person in charge of the open source in your company; they are responsible for keeping an eye out for exploits.

Post Your Comment

Leave another comment.

In order to post a comment, you must complete the fields indicated above.

Post Your Comment Close

Thank you for your comment.

Thank you for submitting your comment, your opinion is an important part of

Your comment has been submitted for review and will be posted to this article as soon as it is approved.

Back to Article

Topics Related to this Article