NEWS AT SEI
This article was originally published in News at SEI on: April 1, 2006
"We’re a U.S. government contractor, and our government customer wants to build a product line by buying core assets from us and then staging an open competition to build products using those core assets. How can we possibly compete on the product-building side when all these new companies enter the fray and claim to be able to build products less expensively because they didn’t have to pay for the core assets?"
First, other contractors can’t necessarily build derivative products less expensively. At best, they can probably build them as cheaply, but even that is questionable. In practice, the core-asset contractor actually may have an advantage on follow-on product development by virtue of its domain knowledge, expertise, and intimate knowledge of the core assets. Other contractors may have a significant and potentially steep learning curve with regard to understanding the functionality and technical characteristics of the core assets, augmenting them with product-specific assets, and integrating and testing them to create a finished product. In fact, it is usually those other contractors that are concerned about the unfair advantage the asset contractor has because, under acquisition reform, contractor experience often plays a large part in the technical evaluation criteria.
All of this indicates the need to create a business strategy that effectively balances the interests of the core-asset contractor and the acquisition organization (and other prospective product-development contractors). The core-asset contractor obviously has an interest in protecting the competitive edge it has in the marketplace. Its core assets are an example of its domain knowledge and software expertise and may be a major factor in maintaining its competitive advantage. Accordingly, there are several options that the core-asset contractor, in conjunction with the acquisition organization, can pursue. They include
selling the core assets outright to the government (with negotiated government-usage rights) while maintaining all commercial rights to the core assets
licensing government usage of the core assets on a per product (or per asset) licensing basis (e.g., the government pays a license fee for each product that is developed using the core assets)
negotiating a follow-on contract by which the asset contractor manages, sustains, and evolves the core assets and provides technical support for product development through the auspices of the acquisition organization
opening up product development to competition through a leader-follower type of contract with the core-asset contractor taking the leader role
allowing the core-asset contractor to compete for product development (the same way as any other contractor) or, alternatively, prohibiting the core-asset contractor from competing on product development
avoiding reliance on any one contractor by letting an umbrella contract (competitively) to multiple contractors that allows them to compete or collaborate on the follow-on development of individual products using the core-asset base; this would allow a greater number of contractors to participate in product development and could allow the core-asset contractor to compete
While there is no one best option, the non-exhaustive list above demonstrates that there are many viable contracting options that can be pursued depending on the goals and acquisition strategy of the government agency and the business strategy of the core-asset contractor.
Finally, if the core assets make it so straightforward to produce products based on them, then the core-asset contractor is in a perfect position to rapidly bring entirely new products to the commercial marketplace, thus taking advantage of the new production capability created courtesy of the government.
"We’re a government contractor who wants to bid on a competition to build products based on core assets developed by another contractor. How can we possibly compete given the intimate knowledge possessed by the asset-development contractor?"
The fact that both this question and the preceding question are frequently asked shows that product lines do not particularly provide an advantage in either direction. In fact, this question is no different than asking “How can I hope to compete because I didn’t build the commercial off-the-shelf (COTS) software or the government-furnished equipment (GFE) that I'm required to use under this contract?” Contractors compete successfully under those conditions all the time. So the premise behind the question—that a contractor can compete successfully only if it is tasked with building all of the software—is just not valid. A pragmatic answer is that your company is no worse off than if the product line strategy had not been pursued.
"I’m a government contractor, and the government wants me to supply reusable core components for other organizations to use in building a product line. Why should I open myself up to the legal liability? I’ll be liable if they use my components incorrectly!"
Liability issues can be tricky. They are negotiated between the acquisition organization and the development contractor(s) and often involve legal counsel. However, in the scenario described in the question, the government contractor would not be directly liable for how another (third-party) government contractor uses its product, and especially if it uses it incorrectly. A contractor who develops components for a government agency is liable to the government—not to another government contractor—to the extent stipulated in the expressed warranties that are part of the contract. There may also be implied warranties of fitness for use for the purpose for which the government will use the items. Contracting officers have to consult with counsel before asserting any claim for breach of an implied warranty.
The important thing to remember is that liability issues are not unique to product lines. The government often contracts for a piece of equipment from one manufacturer and then provides it as government-furnished equipment (GFE) to another contractor to integrate into its final product. In such cases, the liability for the GFE items rests with the government, although the government may have recourse to go back to the original development contractor to have a defect corrected, depending on the contractual warranties that were negotiated and agreed to by both parties.
For commercial items (i.e., nondevelopmental items), liability considerations (expressed and implied) are described in Part 12 (Acquisition of Commercial Items) of the Federal Acquisition Regulations [FAR 97]. General and specific liability considerations that apply to both commercial items and developmental items are described in Part 46 (Quality Assurance) of the FAR.
Specific solicitation provisions and contract clauses on warranties and liabilities that may apply are described in Part 52 of the FAR and Part 252 of the of the Defense Federal Acquisition Regulation Supplement [DFARS 98]. They include the following sections:
FAR: 52.246-18; Warranty of Supplies of a Complex Nature
FAR: 52.266-19; Warranty of Systems and Equipment under Performance Specifications or Design Criteria
FAR: 52.246-23; Limitation of Liability
FAR: 52.246-24; Limitation of Liability, High Value Items
DFARS: 252.246.7001; Data Warranty
The bottom line is that during the contract-solicitation period, any contractor considering bidding on a government contract can formally request that the contracting officer define in writing the extent and limitation of contractor liabilities.
Federal Acquisition Regulation, FAC 97, 1997. The FAC 97-11 version of the Federal Acquisition Circular (FAC) includes amendments effective as of May 3, 1999.
Defense Federal Acquisition Regulations Supplement, 1998 Edition, 1998.
About the Author
Paul Clements is a senior member of the technical staff at the SEI, where he has worked for 10 years leading or co-leading projects in software product line engineering and software architecture design, documentation, and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998; second edition, 2003), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also written dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a BS in mathematical sciences in 1977 and an MS in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a PhD in computer sciences from the University of Texas at Austin in 1994.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.