Most developers today use open source. The benefits are clear: higher productivity, higher quality results. But when improperly managed, much of the value of open source can be erased. Let me illustrate what I mean.
In my previous life, I worked as a development manager at a small software company. Open source became a daily part of our development process. Life was good. And then reality hit us square in the face.
The company was being acquired. During due diligence, it became brutally obvious that while we had documented all open source we used, we had not been sufficiently diligent. Specifically, we had not documented all of the “dependencies”. Open source had made our day-to-day lives easier, but we did not have a full picture of all that was hiding within the open source libraries we used, and how it would complicate our due diligence.
Before the acquisition, we managed our open source inventory manually. We reported on open source components by using a spreadsheet to track them — all manually. But carelessly, we only tracked and accounted for open source libraries we used directly. We missed the open source libraries these components depended on. These “dependencies” were automatically imported with the open source components we used.
The problem was that the “dependencies” were often distributed under different licenses. By ignoring them, we overlooked substantial risks and license compliance requirements. We were lucky, and our omissions turned out not to have a major impact on the actual risks, and on the deal itself. However, we ended up spending substantial time, in one of the most hectic of all times, researching open source dependencies and licenses, and verifying that we comply with their license requirements.
Gary O’Neall, founder of Source Auditor, has been analyzing and auditing open source for over a decade. He says that out of hundreds of software audits, there was only one instance in which they did not find a “surprise — software that was either not disclosed or not known by the software supplier.” He cautioned open source users to be “aware of the consequences of any undisclosed open source software.”
Clearly, I wish I had met Mr. O’Neall before the hard lesson we learned. We could have done without the sleepless nights and headaches.
According to our research at Mend, we found that the average software project contains 64 open source dependencies and an average of 8 different open source licenses. 91% of software projects contain indirect open source dependencies. It is almost impossible to track all of these manually.
Our nightmare story had a happy ending. After six weeks of sleepless nights playing detective and spending a disproportionate amount of time searching the Web for information on our open source components, we closed the deal. We were lucky.
Was it worth the pain, time, cost, effort, last minute pressure, and uncertainty? Maybe. But this time luck was on our side. The risks of missing hidden problems in your open source are NOT worth it. You should always check all licenses carefully and monitor and update your open source throughout the development lifecycle of your project. The best solution is to automate the process. This can potentially save you months of agony and also dramatically reduce the risk of security vulnerabilities. Trust me, you’ll sleep better and the business will benefit.