3. Software Procurement Considerations
In meeting their software needs, covered agencies should give preference to existing Federal software solutions (e.g., Federal shared services or existing reusable source code) or a purchasable off-the-shelf software solutions (e.g., COTS) that can efficiently and effectively meet their operational and mission needs. When a covered agency determines that these alternatives do not meet its needs, the agency may need to procure custom-developed source code built from scratch or built on top of a proprietary solution.
Consistent with OMB policy, in the course of deciding whether a custom solution is necessary, covered agencies must conduct the following three-step analysis (as illustrated in Appendix B). This analysis is intended to mitigate unnecessary spending on custom-developed software solutions by ensuring that existing Federal and commercial solutions, including existing proprietary and/or open source solutions and reusable code, are considered as potential alternatives. In any of the following steps, covered agencies may consider hybrid solutions (i.e., those containing a mixture of existing, COTS, and/or custom solutions) if a preexisting Federal software solution or COTS solution does not—on its own—fully meet the covered agency’s operational and mission needs.15 Furthermore, consistent with OMB policy, covered agencies must evaluate safe and secure cloud computing options throughout every step of the software procurement analysis.16 These steps are consistent with the long-standing OMB policy commonly known as “Raines’ Rules.”17
Step 1 (Alternatives Analysis): When evaluating whether or not to procure a software solution, covered agencies must first conduct an alternatives analysis and demonstrate a preference for the use of existing software solutions for which the Government holds appropriate license rights or ability to reuse. This may include Federal shared services or previously developed code available for Government-wide reuse.
Step 2 (COTS Solutions): If a covered agency’s alternatives analysis concludes that no existing Federal solution efficiently and effectively meets its operational and mission needs, a covered agency must subsequently explore whether an appropriate COTS solution is available. Consistent with OMB’s previous instructions related to Technology Neutrality,18 as part of this process, covered agencies must conduct market research and analyze alternatives that include proprietary, open source,19 and mixed-source software solutions equally and on a level playing field. Covered agencies must then select, if available, a software solution that best meets the operational and mission needs of the agency, taking into consideration factors such as performance, total life-cycle cost of ownership, security and privacy protections, interoperability, ability to share or reuse, resources required to later switch vendors, and availability of support.
Step 3 (Custom Development): If a covered agency’s alternatives analysis concludes that no existing Federal and/or COTS solutions can fully satisfy its operational and mission needs, the agency may consider custom-developed source code. This includes developing a solution from scratch, or developing a solution to customize an existing Federal or COTS product. When developing or acquiring custom code, covered agencies must comply with the policy requirements outlined below.
Footnotes
- 15This analysis is consistent with current Federal procurement policy (See 48 C.F.R. §52.227-17), and the Clinger-Cohen Act of 1996 (See Chapter 7 – Acquiring Information Technology, 40 U.S.C. Subtitle III)↩
- 16Federal Cloud Computing Strategy. February 8, 2011. https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/federal-cloud-computing-strategy.pdf↩
- 17OMB Memorandum M-97-02. Funding Information Systems Investments. https://www.whitehouse.gov/omb/memoranda_m97-02/↩
- 18Technology Neutrality. January 7, 2011. https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/memotociostechnologyneutrality.pdf↩
- 19For purposes of Federal IT acquisitions, OSS must be considered a commercial item and be given appropriate statutory preference per 41 U.S.C. §103 (1)(B), so long as the OSS product is available for license to the general public and meets the other terms therein. When using or modifying OSS, covered agencies are strongly encouraged to consider which license is associated with the software. Licenses affect how the work can be used, modified, and how derivative works must be treated. Agencies must comply with the terms of the licensed work. Government employees and their covered agencies are encouraged to improve the OSS they use and push those fixes to the appropriate code repository. This practice benefits all users of the software because those changes can be distributed widely. This work must follow the terms of the license of the original work. For further guidance, covered agencies should look to Project Open Source at https://project-open-source.cio.gov.↩