Thursday 3 September 2015

Reducing risks in VC investments Part II: investing in software

Here's the second part of a two-part feature on venture capital, risk and investment, by Martin Callinan (Source Code Control) and Kate Andreeva (Protecode). Their first post dealt with general issues regarding due diligence. The sequel, below, focuses on the special issues facing anyone thinking of investing in innovative software.

Technology risk
Not just the software: the business
strategy must be robust too
 
Following the strategy review comes a technology review. In the case of a software-driven enterprise, the focus is typically on the ability of both the software and the development team to deliver on the product roadmap in line with the investor’s timelines. There will be a detailed review of the software architecture, code quality, software engineering quality, scalability, and robustness. 
If the company is a software start-up, an expected pre-requisite is that software development leverages open source software. There may well be valid reasons why a start-up would use open source software but, in the due diligence of a deal flow, the start-up will need a clear and strong justification as to why open source software has not been used. 
The reality is that many young companies do not understand the value of intellectual property and risks that can be engineered into software applications.  The types of risks that investors will look for are: 
  • Software architecture, scalability, and extensibility
  • Exposure to third-party platforms
  • IP value: an objective view of the software’s unique value in the market
  • IP and patent evaluation – are there any patent infringements?
  • Third party dependencies
  • Open source software risk exposure
To identify these technology risks, typically a third party specialist will be contracted to perform a source code review. This review can be initiated by the technology organisation before seeking investment, by the VC or private equity organisation as part of the due diligence process, or both. If the organisation goes into a funding exercise without visibility of the quality of their code and associated risks, there is a good chance that investors will view the investment as risky, regardless of the functionality of the technology in question 
Why due diligence should include an independent source code review
Apart from identifying current issues in the source code, such as licensing irregularities, problematic intellectual property, or potential security vulnerabilities in software components, which typically can be remedied, reviewing the source code can identify inefficiencies and flaws in the development process.  It can also identify the need to have a proper code inspection process during the development cycle, thus eliminating problems before they arise. 
It may be appropriate to create an open source software adoption process with proper tooling, which can help lower compliance costs, not to mention minimising disruptions during key transactions. Similar to bugs in software, it is far more efficient and cost-effective to catch issues early. 
Before discussing source code reviews it is important we are clear what we mean by “source code.” 
What is source code? 
Source code is a set of programming language statements and commands a software developer creates that becomes part, or all, of the applications that use website or device runs. There are a plethora of languages used by developers such as C, C++, C#, Java, or scripting languages such as JavaScript, PERL, Python, or PHP. The source code is compiled into an executable which the target device will execute.
What is a code review or audit? 
A code review or audit should be performed by an independent third party specialist. VC and private equity firms are unlikely to have these skills in-house. A software company seeking investment is however likely to have somebody in-house with the skills needed to perform the review – but that person may not be able to produce a reliable and objective report. 
Why is a code review imperative? 
Developers today rarely code a complete application from scratch. Applications are made up of components of code from a variety of sources which are stitched together to create the finished application. This makes for dynamic and agile development, but with it comes a number of inherent risks. Each component will have a number of attributes, such as how it is licensed and its version. 
Outside of the function of the application(s), investors need to have details of the make-up and provenance of the code components in the following areas: 
  • Intellectual property and licensing
  • Security of the software
  • How the software be maintained and supported
  • The capabilities and maturity of the components being used
  • Ability to integrate with other applications
  • Quality of the components that make up the application
  • Innovation – if the application be evolved over time
  • Viability of the open source community around the components being used
Fundamentally, the review boils down to assessing the overall quality and consistency of the code. The source code is an indicator of the quality of the organisation seeking investment. Software development is a creative exercise and developers should be allowed to express their personal style and approach, but in line with the organisation’s standards which all developers should follow. 
The code audit process 
First, a non-disclosure agreement (NDA) must be in place between the reviewer and the organisation. Once the NDA is in place, the reviewer will question key stakeholders in the organisations to ensure there is a clear understanding of the reasoning behind the audit and the organisation’s environment, such as the size of the portfolio, languages, and tools in use particularly any automatic code generators. A Statement of Work is then produced and agreed upon. This includes:
  • A breakdown of the software portfolio into audit segments 
  • Full automated source code scanning, analysis, and reporting 
  • Resolve copyrights, standard headers, and author tags discovered in the portfolio 
  • Analyse, verify modules, and issue regular audit progress reports 
  • Quality review and sign off of licensing and copyright attributes of every software file in the software portfolio 
  • Delivery of audit report(s), review of the reports.
The report will be reviewed and signed off by the organisation's management. Once signed of the final reports will be completed and delivered to the organisation. The reports will include:


  • Audit Report: a high level executive report, containing information and graphic representation of licences, copyrights, OSS projects, security vulnerabilities, and encryption content within the software portfolio.
  • Overview Report and Detailed file-by-file Reports: verified machine-generated reports on the software portfolio. The overview report should be delivered in pdf format. A detailed file-by-file report should be delivered in in CSV (readable by Microsoft Excel application) format.
  • Concatenated Licence List report: containing a consolidated text of all available licences within the software portfolio in pdf format.
  • Security Vulnerability Report: a cross reference of all security vulnerability information as reported by the National Vulnerability Database in pdf format.
  • Encryption Report: a list of open source software projects detected in the portfolio that could be subject to export control, in pdf format.
About the authors
Martin Callinan has over 20 years’ experience in the software industry with a focus of Software Asset Management, IT Governance, and risk avoidance. He is currently the director at Source Code Control. Martin contributed to Working Group 21, the group responsible for authoring Standards relating to Software Asset Management, such as ISO/IEC 19770-1. In the past, he worked for Microsoft Limited, FrontRange Solutions, Centennial Software, Snow Software, and Express Metrix Limited.

Kate Andreeva is the Director of Solutions at Protecode and has over 15 years’ experience in the technology industry as an engineer and sales professional. With a background in electrical engineering and software development, Kate has honed her skills at companies including Performance Technologies, Level Platforms, Klocwork, and Coverity.

2 comments:

Pamela Chestek said...

Why will there be an export control concern only with open source software?

Pamela Chestek said...

Why is the export control concern only for open source software?