Starting today, US Department of Defense (DoD) administrators and the software developers that work for them will have a clearly defined framework and set of best practices for publishing the software they develop with an open source license. The project, known as code.mil, is being spearheaded by an internal DoD group called the Defense Digital Service (DDS). It’s one of five embedded teams scattered across other federal agencies that together operate under the umbrella of a White House-operated parent organization known as the US Digital Service (USDS). With code.mil now in place, the DDS is also in recruiting mode; looking for developers and other digital experts to help advance its objectives.
Like APIs, one of the chief benefits of open sourcing software is that it paves the way towards re-usability should the publishing organization’s bureaucratic and sprawling nature be enough of an obstacle to the interdepartmental sharing of that code in any other way.
Enter the US Government.
The federal government is in a catch-22 when it comes to open sourcing software that’s developed anywhere within its proverbial four walls. Software created by federal agencies like the Department of Defense (DoD) or the Veterans Administration (VA) is technically in the public domain. But for reasons ranging from culture to fear of cyberattack vulnerability, most agency personnel lack the knowledge and will to take whatever organizational and legal steps are necessary to publish that software under an open source license.
“It’s an unspoken issue” DDS general counsel Sharon Woods told ProgrammableWeb. “The biggest barrier is the perception that open sourcing source code is inherently the most insecure thing to do. Like it’s handing over keys to the kingdom to bad actors.”
Furthermore, despite the public domain status of any code developed by the US government, once such custom code is written to solve a particular problem within an agency, it is often trapped in a legal limbo if there’s no commercial or open source license to go with it. In other words, other government developers (public or private) and agencies are legally prevented from procuring, using or improving it for their own use.
An example, according to DDS engineer Jordan Kasper, is a tool called SALSA that was developed by members of the US Air Force. “SALSA, which stands for ‘Salvaging Static Analysis’ is a malware analysis tool” Kasper told ProgrammableWeb. “Other agencies need this. But its developers had no idea how to open source it.”
Typical of the aforementioned catch-22, the developers of SALSA (who were under the employ of the Air Force) lacked the copyrights to open source the code themselves. And risk-averse military administrators with little or no knowledge about open source software licensing had few if any incentives to blaze a trail themselves. It was easier to just to leave it in place, where in most cases, it would stagnate. Should the need for similar software arise somewhere else within the government, the standard approach was to write it again; a waste of time and more importantly, taxpayer dollars.
Kasper told ProgrammableWeb that “It’s about policy barriers and getting non-technical people on board.” According to Kasper, code.mil is about good guidance for technical people, but mostly for non-technical people who should be thinking about open sourcing the software being developed under their oversight.
Now, on the heels of a Federal Source Code Policy that was released in 2016 by the US Office of Management and Budget, the DDS and its sister groups in the Veteran’s Affairs (VA), the Department of Homeland Security (DHS), the Department of Health and Human Services (HHS) and the Small Business Administration are helping to blaze that trail under the auspices of the USDS which is headquartered in the White House.
According to USDS spokesperson Cyrus Sethna, the hope is that more similarly inspired “startup” groups from other agencies will join the effort thus paving the way towards even more inter-agency sharing of code. Given the size of the entire federal government however, Sethna told ProgrammableWeb that USDS priority will be given to agencies with public facing platforms (ones that citizens touch), problems that stand the greatest likelihood of being solved (few or no human limitations), and that are developing solutions with the greatest potential for scale (re-use).
Since the DDS’ co-founding by its director Chris Lynch (who reports to US Secretary of Defense Jim Mattis) and DDS chief of staff Reina Staley, the unit has grown in size. “We went from an empty office with file cabinets and wastepaper baskets to having a legitimate office with 30 amazing digital experts” said Staley during the briefing with ProgrammableWeb. Including the DDS and its sister groups in the other agencies, the USDS has more than 200 people in its organization.
Depsite being 30-strong, the DDS is still growing. According to Staley, one of the DDS’ biggest obstacles to success is finding “great” people to help take on their mission. “We’re always looking for talented people who believe firmly in building a better government” said Staley. “Whether you’re already a full-time government employee or contractor or someone looking for a new opportunity, we use a salaried Tour of Duty model. With the average tenure lasting about a year, it’s not meant to be a lasting career. Some people take a leave of absence from their job to come work for us.”
The group is looking for help in four main competencies; engineers, product managers, designers, and bureaucracy hackers — people with the tenacity, determination and patience to navigate the government’s typical operational barriers. According to the USDS’ Sethna, “folks who are interested in getting involved can check out who we hire on our website and then fill out this form to connect with a recruiter.”