Open Source Software in Mergers & Acquisitions

Posted in
Placeholder

We have been involved in business deals which have foundered simply because the acquiring/procuring party did not know the right questions to ask or the right people to involve, or conversely the target/selling party did not have the resources or knowledge to adequately respond to those questions.

Imagine a hypothetical transaction involving the purchase of a candy manufacturing business. The purchaser’s due diligence questionnaire includes questions about the number and type of product recalls or liability lawsuits the business has been subjected to over the last 10 years. How will the transaction progress if no answer is provided or the answer is couched in vague or general terms such as: “we maintain high manufacturing standards through our policies and processes”.

Now imagine a similar transaction where the target is a financial services company using specialized software solutions for various aspects of its critical customer functions, such as data security. This time the due diligence questionnaire includes questions about the use and deployment of OSS. The target responds similarly to the chocolate manufacturer that it does use OSS, has had no issues and has policies and procedures in place to ensure maximum security.”

Let’s assume for now that the strategic importance of the transaction for the purchaser is equivalent in both cases. In the first case, it’s hard to imagine the buyer and its lawyers being prepared to take the response provided at face value. There will be extensive searches of public records carried out. There will be site visits to verify the processes and procedures in operation. There will be interviews with the target’s internal legal and technical team and other risk management professionals and where external counsel is used there will likely be requests for verification from the target’s external lawyers and auditors. Even after all of this, the purchaser’s legal team will have inserted wide ranging warranties and indemnities in its acquisition agreementin order to circumscribe its warranty and indemnity risk.

Now consider the second case and the difference is immediately evident. No amount of site visits, external research or public record verification will likely reveal much of the true nature of any risk associated with the target’s use of OSS. External service providers such as lawyers and accountants will be able to provide little if anything for the buyer to rely on. Interviews with the C-suite executives will probably take you little further other than perhaps to give you a general impression of how seriously they have taken the topic of OSS management. Interviews between expert teams, if you get that far, might elicit some meaningful revelations but more often than not there will be an imbalance of relevant expertise on one or other side of the table. Critical questions will not be asked or properly understood. Inadequate responses will not be challenged.

Two possible consequences follow for the progress of the second transaction. The purchaser or one or other of its key decision makers gets cold feet and the project is discontinued, or the topic is brushed under the carpet leaving one or other or both (depending on the warranty and indemnity topic mentioned above and assuming some agreement can even be reached) exposed to uncertain financial and legal risk. In either case the outcome for one or other party and its shareholders could be dire.

Of course there may be many reasons aside from OSS risk, why an acquisition project or product procurement exercise might be abandoned or might turn out to be highly unsuccessful for one or other of the contracting parties. However as software proliferates exponentially and the quotient of OSS in that software also proliferates at a more or less steady pace across multiple industry sectors, it is a reasonably fair assumption that OSS risk will become an increasingly common reason given for the abandonment or ultimate failure of a corporate procurement endeavor.

The solution? Mastering OSS across all functions of your organization: meaning every corner of the business operations in which OSS does or potentially could play a significant part.

The scope is wide. The example given above is merely an illustration of risk at one end of the OSS spectrum. Some businesses and the principles underlying their valuation may quite literally stand or fall on the basis of their response to OSS.

Your mOSS team