Introduction
Software systems, and efforts to develop them, are growing increasingly complex. In the past, software commonly operated in a stand-alone manner and often was built to meet a business’s detailed specifications. Today, most software must interact with a range of external systems. Development happens rapidly, often without detailed specifications, based on evolving goals, leveraging open source software, “SaaS” offerings and other pre-existing building blocks. While these trends reduce development costs, shorten project timelines and offer new capabilities, they also increase the complexity of software development and undermine traditional contracting and licensing approaches. Today’s contracts for complex software development should therefore be different than those for traditional software.
This article will describe key trends in modern software development and related contracting concepts, the impacts of using of open source and other third-party software on software development, and the management of software integration with SaaS offerings and other changing third-party systems. This article will also explore contractual approaches to mitigate risks and promote the success of the software development process.
What Makes Today’s Software Systems So Complex?
Today’s software systems provide capabilities unimaginable before the rise of the Internet and cloud computing, while at the same time keeping the extreme complexity of these systems largely hidden from users. Everyday examples include ecommerce websites that process sales transactions, enterprise resource planning (ERP) systems that manage the operations of global companies, IoT (Internet of Things) applications that process streaming data from large numbers of remote distributed sensors, and mobile navigation apps that generate routing guidance from real-time location data collected simultaneously from a multitude of users. A key common thread among these systems is their integration with a variety of external systems. By comparison, the stand-alone software of the past (for example, an accounting system running on a mainframe computer) seems simpler, and frankly, quaint.
Not surprisingly, as features, capabilities and integrations of modern software have grown, so has the complexity of the effort to develop and implement such software. One commentator described the situation in the following way: “There are lots of moving parts and they’re all buried under lots of other moving parts, so that you can’t even see half of them!”1 Managing the changes and integration points can seem a bit like changing a tire on a moving car.
Even if more complicated, by comparison with the software of the past, today’s systems can often operate with increased stability and be deployed faster and at lower costs.2 One reason for this trend is the proliferation of collaboration in software development, including the use of open source and other third-party code.
Open source software can provide up-front benefits by reducing the amount of custom code in a project, and providing proven technology, thereby shortening the time it takes to create working software. As a result, the use of open source software has increased significantly in recent years, with 86 percent of organizations reporting that their use of open source software increased or remained constant in 2017.3 In similar fashion, developers have increasingly turned to SaaS and other “as a Service” offerings to reduce the scope of software development projects, improve serviceability, and reduce the ultimate cost of ownership. According to a 2016 survey, 49 percent of companies used one or more SaaS solutions and another 23 percent planned to implement at least one SaaS solution within the next 12 months.4
However, despite the benefits of using these building blocks, there are disadvantages. Open source and third-party code and SaaS offerings are dynamic, subject to performance problems and security vulnerabilities, and are not within the control of the business or the developer. For example, a change or error in third-party code or a SaaS offering may create incompatibilities or malfunctions in other parts of the software. In addition, as has been widely discussed elsewhere,5 open source software risks can create a variety of legal issues, including (i) the risk of being required to share a business’s proprietary technology with third parties or without charging a fee, (ii) the absence of warranty and protection against infringement risks, and (iii) the potential for conflicts among the various license terms that govern open source code. Managing these concerns is a major challenge in modern software development. Each aspect of the project, including items from third parties, must be managed so that the software building blocks and use of external software continue to meet project specifications, remain compatible with the project-at-large, and can be used without license conflicts or compliance issues, all while avoiding a major delay to project execution. This challenge is even greater where the project lacks an agreed upon contractual framework for reviewing and approving the use of third-party building blocks.
Traditional Software Development
Traditionally software development was based on a set of practices known as the “Waterfall” model. This model is characterized by a sequential process with clearly defined steps (for example, design precedes coding, and coding precedes testing, and testing precedes deployment). Because it is linear, the Waterfall model is often viewed as inflexible.
But the Waterfall model is often well-suited for projects where (i) detailed specifications for the software to be developed exist at the project start, (ii) there is limited use of third-party code (i.e., there is significant custom code developed), and (iii) the software to be developed will have limited interactions with external systems (such as with an application that executes in a stand-alone manner on a workstation or mobile device).
Contracts for Waterfall projects mirror the structure of this model. For instance, such contracts often (i) incorporate a schedule listing detailed specifications and delivery dates, and (ii) tie acceptance of, and payment and warranties for, deliverables to their compliance with specifications.
Development Methods for Today’s Complex Software
The Waterfall model may provide a useful starting point, but it is often a poor fit for today’s software development projects. As noted above, modern software development often relies more on the use of pre-existing third-party building blocks and linkages to external systems, and less on the creation of custom code. As more third party elements are added to a project, it becomes ever more difficult to analyze potential compatibility and other interactions among these elements and to define specifications for the entire project. In addition, businesses today require more rapid development and deployment of software to gain market advantage and to keep pace with evolving technology, such as use of social media platforms. Those businesses want to start development without the time-consuming job of defining specifications in advance.
In response, Agile and similar software development methodologies have become popular alternatives to the Waterfall model. While the details of each vary, such methodologies generally (i) enable development to happen rapidly without detailed, up-front specifications, (ii) accommodate evolving business goals for the final product, and (iii) emphasize early and continuous delivery of software to the business.6 For example, Agile accomplishes this by breaking down the project into smaller units, each with its own coding and evaluation iterations, and enabling the business to change the direction of (or even terminate) the project at any point.
Due to its flexibility, Agile has become commonplace in the software development industry with 77 percent of software development companies reporting the use of Agile for their projects.7 Yet Agile is not without challenges for lawyers and their business clients. For instance, it does not mitigate the difficulty of managing the use of third-party building blocks and the external systems that need to be integrated with the software being developed (and which could delay or derail the project). In addition, without detailed up-front specifications, businesses may have less certainty regarding the features, price and delivery date of the final product.
Likewise, the lack of detailed up-front specifications undermines traditional acceptance and warranty provisions, which are based on deliverables meeting requirements, and that places a greater burden on businesses when they need to show that a final product is deficient. Agile and similar methodologies are designed to provide “workable” code in a series of short term, smaller pieces of projects. Typically, businesses have relatively liberal termination rights, which allow exit at any point during the project. However, businesses often find that walking away from a developer is not a practical remedy. For instance, even if workable code is delivered with each coding cycle, the business may incur significant additional costs if it terminates and a successor developer needs to analyze and possibly rewrite parts of the original developer’s code. In other words, once the business invests in an Agile-development project, it may need to invest much more than was originally budgeted to achieve the desired outcomes or risk scuttling the project entirely and losing the value of the original investment.
What Can Be Done to Mitigate Risks in Complex Software Development Projects?
- Document key requirements and success factors to evaluate the results of the project. As noted above, projects for modern software development often start without detailed up-front specifications that tie milestone acceptance and warranties to compliance with requirements. Even without such detailed specifications, the modern software development contract should document, at a minimum, (i) the business objectives to be met, the promised value to be delivered, the desired outcomes and other criteria for evaluating the “sufficiency” of the final product, and (ii) key system requirements, such as the technology stack to be supported and requirements for compliance with specified standards. For example, these criteria could include a minimum percentage increase in processing speed over the business’s legacy system, or require the successful deployment of the software for a specified number of end users. It is also important to keep in mind that even where specifications for the software are to be developed during the project, the scope and pricing for other developer services (such as ongoing maintenance, support and hosting services) should be detailed in the contract.
- Set rules for using of third-party building blocks. The modern software contract should specify guidelines for third-party building blocks, including (i) compliance with the business’s open source software and IT security policies and, if applicable, technology architecture standards, (ii) the business’s right to review and approve the use of such building blocks, including governing license and other legal terms and impact assessments prepared by the developer, (iii) an allocation of responsibility for licensing such building blocks (in terms of both administrative and financial responsibility), (iv) the requirement for the developer to provide bills of material and, if applicable, the results of open source code scans, with each delivery of the software, so that existence of open source and other third-party materials are known to the business, and (v) the business’s rights to assume the developer’s license to such building blocks (for example, at the end of the project).
- Due diligence of third-party building blocks. Before approving the use of any third-party building blocks, the customer should confirm, among other things, (i) the stability, maturity, quality and security of such item, (ii) that the legal terms governing such item permit the business’ intended use for the software and confirmation that there are no conflicts among the various governing legal terms, and (iii) the availability, cost and terms of support and maintenance of such item. The contract should also detail what happens if the project begins but the business ultimately does not approve the key building blocks for the project.
- Address the impact of changes or other problems in third-party building blocks and external systems. Third-party building blocks to be used for, and external systems to be integrated with, the software are subject to changes and problems, as well as the risk that the third-party provider will disappear. The modern software contract should address these issues by specifying (i) which party is responsible for identifying, assessing and bearing the costs of such issues and managing the relationship with the applicable third party to resolve problems as they arise, and (ii) the business’s right to approve the handling of such issues (whether through rewriting code, using a replacement product or eliminating a feature). As changes occur, the parties should evaluate any impacts on project objectives and success factors to validate that they remain relevant. In addition, depending upon the criticality of the third-party component, it may be appropriate to require that the applicable provider establish a source code escrow arrangement for the business’s benefit (for example, in case such provider becomes bankrupt). Businesses should also take into account their need to have control over changes when considering whether to require a private or public cloud implementation of a SaaS offering.
- Additional (non-software) approaches to mitigate risk in modern software development projects. In addition to the items described above, businesses should consider addressing broader contract risks in software development projects, including (i) liberal rights for the business to terminate and to receive object and source code for the software and a broad license to the developer’s intellectual property, all to permit the business’s continued use and development of the software, (ii) warranties regarding sufficiency and qualifications of the developer’s resources working on the project, (iii) the right to hire (or at least to receive knowledge transfer from) the developer’s personnel working on the project, and (iv) avoiding giving the developer exclusive rights to develop the software or other commitments that may restrict the business from engaging a successor developer.
Conclusion
While modern software offers a range of new features and capabilities, it is more complex and dependent upon integrated third-party components than ever before. This complexity creates challenges for traditional contracting approaches that measure outcomes based on compliance with detailed up-front specifications. By understanding and anticipating these challenges, lawyers can guide their business clients toward more flexible contractual approaches that mitigate risk and promote the success of the project.
1 Danny Bradbury, “How to Secure a Software-Driven Technology Stack in a Cloud of Moving Parts,” The Register, https://www.theregister.co.uk/2017/11/01/how_to_secure_a_softwaredriven_technology_stack_in_a_cloud_of_moving_parts/.
2 For example, McKinsey & Company found that “companies can reduce the average number of days required to complete code development and move it into live production from 89 days to 15 days, a mere 17 percent of the original time” by adopting DevOps practices. Oliver Bossert, Chris Ip, and Irina Starikova, “Beyond Agile: Reorganizing IT for Faster Software Delivery,” McKinsey & Company, September 2015, https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/beyond-agile-reorganizing-it-for-faster-software-delivery.
3 Black Duck, “Open Source 360° Survey,” https://www.blackducksoftware.com/open-source-360deg-survey
4 James Sanders and Meghann Agarwal, “Software as a Service: Adoption rates, business benefits, and preferred providers,” Tech Pro Research, January 2017, http://b2b.cbsimg.net/downloads/TRPro/Tech-Pro-Research-SaaS-Report-2017.pdf.
5 Derek Schaffner, “The Risks of Open Source Software in Outsourcing Transactions,” Business and Technology Sourcing Review, https://m.mayerbrown.com/Files/Publication/891b2c9a-ceff-4ae9-be20-d5f879bc3927/Presentation/PublicationAttachment/f9a67ec3-5786-4c9c-8d46-9cf97b5efe5f/ART_RISKSOFOPENSOURCE_0308.PDF.
6 For example, the Agile manifesto asks developers to “Welcome changing requirements, even late in development.” See http://agilemanifesto.org/principles.html.
