The most important asset most tech companies possess and hold dear to their heart is their source code.
Whether its artificial intelligence, automated cars, Internet of Things or enterprise security, our business and personal lives are driven by software. Thus naturally when a company acquires another, the source code behind the acquired products represents a major contributor to the value of that acquisition.
The way source code is conceptualized, structured, written and managed in companies has dramatically changed in the last 15 years. Until the late 1990s when open source and cloud computing concepts were not as prevalent, most source code was developed in silos where a comparatively unchanging developer team would write and maintain an organizational monolith of code. It made it easier to store and access and understand - but such development also made it much harder to train new developers on and limited the speed at which increasingly complex software products could be written.
Fortunately however, as we continued to demand more and more tasks to be automated and simplified using software, two major developments came along that changed how the technology industry developed software regardless of the language, platform or market segment.
VERSIONING AND SOURCE CONTROL SYSTEMS filled an important need for code to be archived, tracked and versioned as developer teams grew in size as well as geographic displacement. Such versioning systems automatically store each changed version of the code, easing maintenance and enabling larger teams of developers but at the cost of burgeoning amounts of code storage.
OPEN SOURCE SOFTWARE democratized development of complex software in a way that not only increased collaboration and sharing of skills but also shortened development lifecycles and reduced costs. With open source software, developer teams were no longer limited by the skills of just their team members - which accelerated software technology albeit with increased compliance requirements and diluting proprietorship.
Both developments also mushroomed important concerns for companies when they acquire other software companies or products. For example, as teams have grown in size and products have grown in complexity, it can become a challenge for the buyer company to scale a product (and get a good return on investment) if the source code has not been maintained, documented and versioned appropriately. Google’s source code spans over 2 billion lines of code while Microsoft Windows 10 has over 50 million lines of code (source). Even a modest iPhone app can contain upwards of 250,000 lines of code per version. Multiply that with all the different versions of the code during development and maintenance – and you can imagine how difficult it can get for companies to store and maintain the entire codebase. Companies that do audit and enforce good development processes use a variety of metrics to assess if their developers are following guidelines:
Comment density
Number of classes and interfaces
The problem however is that most companies – especially medium sized businesses and organizations with up to a few hundred developers – do not start monitoring code quality from the start, and by the time of an acquisition are far too along in the process to go back and calculate or improve their metrics. This “if it ain’t broke, don’t fix it” approach saves cost and effort only until the technology gets acquired and needs to be scaled up by anyone who didn’t originally write the code – at which point the acquiring company wastes time and money in fixing it.
Further, when software products grow to span dozens of modules, thousands of files and millions of code lines – it is very probably that sizable portions come from open source software repositories. In one 2015 survey, 78 percent of C-level executives said their companies run part or all of its operations on OSS and 66 percent said their company creates software for customers built on open source. 60-70 percent of the companies contributed to open-source projects. Those are big numbers showing how pervasive open source software has become. On the other hand, the survey also revealed some alarming numbers:
More than 55 percent of the companies have no formal policy around open-source use – leaving it open to developer teams to choose and decide whether to use open source software. Moreover, only 27 percent have a formal policy for employee contributions to open source projects. Only 42 percent maintain an inventory of open source components.
To make things worse, most developers ignore, or are ignorant of the fact just because a source code repository is marked open source and freely accessible on the Internet, it does not necessarily mean that code can be used freely and without restrictions.
Open-source software usually comes with detailed licenses that may for example restrict use of the code in commercial products or require that the source code for the end product be made available for free as well. In a competitive market, these restrictions can make or break the total market value of the acquired products. It is thus important for an investor to know which code modules are covered under license regimes like GPL, AGPL, LGPL, Apache, etc. – each version of which comes with its own set of liabilities.
Investing in a strategic code audit as part of your larger M&A due diligence effort can help raise such red flags and prepare for what comes after the investment. An ideal code audit should provide at least the following 10 key insights:
What portion of the code is proprietary to the company and what portion is from third parties?
What are the various processes and systems used by developers to write code – and are there any security or functionality gaps in those systems?
Is the code structured such that it is easy to add new functionalities or deploy in new environments?
Is the code appropriately versioned with dates, authors and version numbers?
Is the code appropriately documented and commented such that it is easy to train new developers on?
Does the code adequately mark trade secrets and copyrights?
What portion of the software constitutes open source software and what open source licenses apply to particular code modules?
Does the product/company comply with each governing open source license and what actions are needed to circumvent or comply with the license?
Are there security gaps in the code that can facilitate theft of trade secrets and customer data?
Is there patentable subject matter within the proprietary portions of source code?
At just 0.3% - 0.5% of the total cost of an investment, a well-structured code audit provides confidence to the investor, alerting important red flags that can present legal and security challenges to the product that can otherwise go unnoticed during routine M&A due diligence efforts and at the same time help management implement industry best practices for sustainable product development.