Over the years I have been involved in several startups as a founder, advisor and investor. I also had the good fortune of being part of a couple of acquisition processes.
As you probably know, due diligence processes in software M&A deals include the investigation of the acquired company’s intellectual property and open source usage. In two similarly structured acquisitions, providing the information required for this investigation turned out to be a totally different experience.
In both cases, the acquirer asked for a list of open source components (inventory), complete with all licenses, relevant documentation, usage, etc. So why was the experience in these two cases so different?
While small, this company was quite diligent in screening and recording the open source components that were used by its developers.
The VP of R&D was using a spreadsheet to inventory open source usage.
The information in the sheet was provided to him by the developers whenever they adopted new open source libraries, as part of an informal approval process. When Company A received the due diligence questionnaire, it quickly provided this spreadsheet.
The first feedback from the due diligence team was that the information recorded in the spreadsheet was insufficient, and a little more documentation was needed. Then reality hit…. The spreadsheet was missing a huge number of “dependencies” – the open source libraries that are used by the open source libraries that the company was using. The list grew from ~30 items to ~300. Further investigation revealed that additional open source libraries were not reported, and that some reported libraries were no longer in use.The spreadsheet was stale, incomplete and inaccurate.
This meant a lot more work, right up to the last minute before signing. Because of the initial inaccurate report, the acquirer decided to run a thenstate-of-the-art source code scan, to try and identify open source that Company A may have failed to report. Hundreds of additional hours were spent on sifting through thousands of false warnings that were reported by the scanner. Had the scanning process revealed libraries with restrictive licenses, the deal would have fallen through, or at least delayed until these libraries could be replaced.
Company A had to go through a nerve wrecking and time consuming process at the worst possible time. All’s well that ends well? We thought that it should not be so hard.
This experience led us to develop the WhiteSource solution. At the time, open source management solutions were based on code scanning. For most companies, these solutions are too expensive to buy and deploy.Furthermore, they significantly disrupt theagile software development lifecycle.
Our goal was to facilitate large scale adoption of open source technology by making the management of open source components easy, simple and part of the software development lifecycle. Our new approach (which does not rely on scanning code)reduces the costs of managing open source and relieves developers of the burden and responsibility associated with it.
Company B was a beta site for WhiteSource. When the open source due diligence request arrived, the only thing that had to be done is to generate a Licenses Report in the WhiteSource system – a click of a button – and hand it to the acquirer. That was it.
Because Company B used WhiteSource before the M&A process, its open source inventory was well managed, and there were no open source components with challenging license or security vulnerabilities in its code.
The acquiring company received a clear, full, up-to-date and detailed report. Both the acquirer and Company B were able to focus on the M&A process itself. All’s well that ends well, again, but this time it also started well.