Air Force Software Policy Faces Backlash for Stifling innovation
Teh Department of the air Force’s recent policy shift regarding software acquisition is drawing criticism for possibly hindering the very innovation it aims to foster. Announced via a contractor’s LinkedIn post and amplified by the chief innovation officer, the new guidance, tagged with the promise of “Strategic shift, operational clarity,” is being described by industry experts as a step backward for the military’s burgeoning software ecosystem.
The roots of this debate lie in the Fiscal Year 2018 National Defense Authorization act, which tasked the Defense Innovation board with streamlining software progress and acquisition regulations. The resulting Software Acquisition and Practices Study, delivered in May 2019, fundamentally argued that “software is diffrent than hardware (and not all software is the same),” advocating for prioritizing speed and leveraging existing commercial software whenever possible. This report served as a “clarion call” to modernize defense acquisition processes, a charge the Air Force initially embraced.
From the outset, the Air Force led the charge, pioneering continuous authorizations to operate, establishing software factories like Kessel Run – pairing active-duty personnel with industry developers – and creating department-wide shared cloud environments. The service also championed the Small Business Innovation Research Open Topics and Direct-to-Phase-II awards, opening doors for startups with commercially viable products.
Though, recent guidance from Air Force Director of Administration and Management Nancy Andrews and Acting Deputy Chief Information Officer Keith Hardiman is now threatening to unravel this progress. A memo,initially shared by a contractor on LinkedIn and then re-shared by the Air Force’s chief innovation officer,attempts to regulate the acquisition of Software-as-a-Service (SaaS) offerings,but critics fear it will “kneecap the burgeoning defense software industry.”
On the surface, the guidance offers some positive aspects. It defines SaaS as an submission delivered via a cloud interface, tying costs to consumption – a principle long advocated for by modern software startups. The logic is straightforward: if a product isn’t used, the government shouldn’t pay, and successful products should be rewarded. A key concern addressed in the memo is data portability, recognizing the need for the government to retain access to its data even when switching platforms.
Despite these intentions, the policy is being widely viewed as unnecessary and duplicative. Thanks to the Office of federal procurement Policy and the Federal Acquisition Regulatory Council’s “Revolutionary federal Acquisition Regulation Overhaul,” Part 16 already promotes flexible contract types, including consumption-based pricing. “Requiring this model for software-as-a-service just creates definitional challenges,” one analyst noted, “leading to arguments over what constitutes ‘software-as-a-service’ versus simply ‘software.'”
The core of the problem, according to industry insiders, lies in three critical mistakes made by the
