Image: iStock/AmmentorpDK
A report from the Center for a New American Security argues that the Department of Defense (DoD) risks “being left behind” due to continued overreliance on proprietary software.
The DoD has been on the vanguard of open source advocacy for many years, first clearing the way to broad internal adoption in 2009 with guidelines suggesting open source could be superior to proprietary software in some use cases. More, however, is needed.
The more that is needed isn’t a new policy. Rather, it’s a fundamental rethinking of the importance of developers and how they access code, and not necessarily the code and its associated license. The report notes that “Software development is not currently a high-profile, high-priority topic in the discussion about diminishing U.S. military technical superiority,” going on to aver, “It should be.” This is spot-on, and points to the role developers must play to make the DoD (or any organization) responsive to ever-shifting demands.
It’s not about a license
The Center for a New American Security’s report ultimately offers a call to action: “The DoD must overcome bureaucratic hurdles and embrace open source software as a critical element of its efforts to maintain military technical superiority in the 21st century.” Along the way, the report mentions a litany of familiar reasons for embracing open source software: decreased costs, increased agility, etc.
What it almost entirely fails to mention is the central role developers play in making that open source software sing.
SEE: States show the US federal government how to go big in cloud
Perhaps the authors assume everyone understands that developers are “the new kingmakers,” to borrow a Redmonk phrase, and that their tool of choice is open source (running in a public cloud). Indeed, a few scattered statements seem to confirm this implication, including this one: “Open architectures enable software developers to create new features and users to easily install them.”
Yet the fundamental promise of unshackling developers through liberal license terms and cloud-based hardware goes mostly unremarked. Perhaps this derives from the realization that there are institutional barriers to both the idea of open source and its adoption:
There are very real human and cultural factors that create a perceived mismatch between open source methods and DoD acquisition. The Pentagon is a hierarchical organization, which naturally leads to top-down methods of technology management through formal requirements. This approach tends to be risk-averse and stifles experimentation, innovation, and rapid implementation. In contrast, open source grows without direct supervision or control, and relies instead on collaborative, bottom-up development of solutions to problems.
Even so, the authors recognize that open source encourages that developer creativity to route around calcified bureaucracies: “Considering the DoD’s top-down apathy toward and difficulty with using open source methods, one glaring question remains: Why is there continued bottom-up support for open source software and methods within the DoD?”
Because…developers.
You have nothing to lose but your chains
The authors, wittingly or unwittingly, understand that something is happening deep in the bowels of the DoD, and that something is developers. Developers, tasked with “getting stuff done,” are doing it with open source. More, however, is needed.
The authors acknowledge “widespread consumption of open source software in the DoD,” yet also insist that “we can do so much more.” What’s the more? “We need to go from simply consumers of open source software to using open source principles as a way to do business in the DoD.”
They sketch out a series of platitudes about open source, but don’t articulate tangible things that would boost developer productivity, beyond advocating “more open source.” Arguments for public cloud, developer tooling, or other mechanisms for boosting developer productivity go missing.
SEE: How Allstate boosted developer productivity by 350% with the cloud
This is an error, because by the authors’ own admission plenty of open source software is in use. Developers are bringing it in regardless of decrepit bureaucracy above them. To more fully unshackle those developers, the report authors should have pointed to where developers want to run open source software: public clouds.
In other words, where those developers still need help is in bursting free of the operational (read: hardware) hurdles that strangle their ability to move fast. Some of these hurdles are toppling with the acceptance of AWS (GovCloud) and the introduction of the DoD’s own milCloud, but more is required.
Rather than agitating for more open source software, the report should have advocated that developer productivity be increased through more public cloud allowances. The underlying value derives from developers, but requires open source software and cloud hardware to really thrive.
Also see
Source link
DoD: Time to rethink how your open source developers access code
Sem comentários:
Enviar um comentário