Army officers and writers Crispin Burke, Niel Smith, and James King have a fascinating piece on the DCGS-A (Distributed Common Ground System-Army) contretemps. It rightly goes beyond blame and finger-pointing. Let me lay my own bias out front — Palantir is a fantastic company, there also many amazing and hard-working military tech people, and Rep. Duncan Hunter’s frustrations are also (as Burke et al explains) understandable. I see no villains here.
There are systemic reasons for why Army users struggle with Army systems: lack of interoperability/commonality, and the overall mismatch between Army IT development practices and the Valley way. It’s a great piece, and I encourage readers to mosey over to Small Wars Journal to see how endless hours of Burke complaining about AKO (the reflector belt of Army IT) finally became productive.
In particular, I would like to highlight one Burke-Smith-King bullet of interest:
Code the software using open concepts, and design the software for user modding. Army software is often locked into proprietary specifications of the vendors. However, the commercial software and gaming industry often encourages add-ins and “mods” to their software that enhance the user experience. In many cases, these mods are incorporated into later versions of the programs. The Army should leverage the ingenuity of its tech-savvy soldiers to constantly improve and refine the systems they operate.
A major part of DCGSC-A is now open source. But I’d like to expand a bit on the quoted bullet.
One of the major problems the Army users quoted in this somewhat inflammatory The New Republic article talk about is their difficulty fitting components of DCGS-A to user requirements. Though much of this has to do with the more generalized problems Burke and others talk about, one could also plausibly see problems that issue from unique operational requirements.
Tom Ricks famously said that different geographical regions of Iraq felt like entirely separate wars. In Afghanistan, then-Major General Michael T. Flynn wrote about the need for atmospheric and specific intelligence on local conditions. No one software program has everything or can do everything well, and the military and intelligence community that is increasingly asked to do (in breadth and depth) more than ever. So what to do?
In the computational social science community, we deal with this issue by generating new packages that serve a local and specific need. I use the programming language Python for my coursework, and Python has an active user community that contributes, standardizes, and validates packages. If I want to do something with statistical algorithms, I import the pandas package into my interpreter. If I want to use network analysis, I import networkx (a package that former intelligence analyst and current private sector data scientist Drew Conway has said stands up to some of the best social network software in the defense community). You can do statistics without pandas, but your own improvisational solution might not be as good as something as tested and popular as the pandas package.
It is because of this flexibility and tight user community that the statistical programming language R is quickly threatening closed-source industry leaders in popularity among all manner of data science career areas. In my own whimsy as an academic egghead PhD student, I wondered–following Burke’s modding suggestion–if something close to my own experience with Python could be replicated. Operating in a particularly rough part of the world and your mission software needs some extra functionality? An package could be designed to solve the particular problem.
Most importantly open-source programming languages and software can at least theoretically interface with the proprietary products often used in the federal space. The software giant ESRI has built a Python interface for its popular ArcGIS geographic information system program. And one can also use open-source software in development environments that go easy on users without much programming experience. Though I personally prefer the Spyder Python development environment and iPython Notebook, some of my classmates use Enthought’s proprietary Canopy development environment. I am a little (though not by much) more used to importing packages from the command line and navigating repositories. So I feel more comfortable installing my necessary packages from my Linux virtual machine’s terminal, not Canopy’s easy-to-use package manager.
I don’t know if it would be possible to replicate the freewheeling community of users seen in the open-source community within the military. In fact, when I posed this question to a group of military IT insiders in a email chain, they (rightly) told me that it was fantastic a vision as the Iraq and Afghan war strategies. There were many trenchant observations, many of which focusing on uneven/outdated IT knowledge. But two in particular struck me as particularly telling.
Even though Python has a “benevolent dictator for life” it also depends on a vast, freewheeling community of users. A closed-source version of Github would not benefit from this, and thus there would be less advantage for a soldier or intelligence community analyst to work on their own time (unless specifically incentivized by their boss) to develop, say, a Helmand or Nuristan package. Even if we could get something like that, the security requirements, organizational stovepiping, and bureaucratic politics that characterizes the military-industrial complex might act as a limiting factor on the size and viability of a military modding community.
Lastly, software is iteratively improved in the open-source due to a large group of people attacking bugs and improving on the original design. Without a sufficiently large and diverse community, a military/intelligence community mod group would not really be as effective. And if I download a package that hasn’t been sufficiently worked over, the worst that might happen is that my class model would run more slowly or output spurious results. A military package that doesn’t work correctly could have much more serious consequences.
That said, I don’t think the vision I lay out is completely improbable. The aforementioned networkx package was developed by the government-run Los Alamos National Laboratory, demonstrating that a federal ecosystem could also be a player in open-source development (little known fact: TOR also grew out of a federal project). And the community of practice fostered by Small Wars Journal, Disruptive Thinkers (and its DEF spinoff), the Warlord Loop, CompanyCommander, and other informal groups suggests precedent for some precedent for a military/IC modding-like system. As a civilian on the outside, I would also be curious to see what the intelligence community’s experience with similar forums on closed networks like Intelink, SIPR, JWICS, or the Open Source Center have been (for example, the much-heralded Intellipedia).
Burke, Smith, and King are bright young officers, and I hope their crusade for better Army IT meets with success. And even if an military officer or government civilian probably won’t be able to just type my Ubuntu terminal command and get a package from a repository, the vision of modding Burke and his friends suggest would help IT be more responsive to government and military needs. That said, I can reliably predict that AKO will torment Burke even after he eventually leaves the Army. :)
For more on this topic see our reporting on National Security and Technology
