Page 34 - GCN, May 2017

OPEN GOVERNMENT
engaged are companies’ leadership and employees with those communities?”
Jones seconded the emphasis on ac- tive contributors, and he suggested looking for vendors “whose default is to mainstream the customizations” back into the open-source project — wheth- er in the main codebase or via plugins or a FOSS fork. Those firms “are going to be focused on selling you the new code they have to write to meet your specific needs and not trying to profit
chief data officer, however, he “was a govvie who wanted to use open-source tools” — and he found himself in an up- hill battle.
“I went into government in 2010,” he said. “In the first couple of years, there was a lot of resistance.”
Much of that resistance centered on security. “Maintaining security compli- ance on a project built with open source is not harder than it is with proprietary software components,” he said. But with commercial software, “people feel that they have someone identified as account- able. And they’re unsure who’s account- able when it comes to open source.”
In truth, Elin said, proprietary soft- ware licenses explicitly state that the vendors “are never accountable and will pay no penalties for anything that goes wrong with their software.” He stressed that it’s the agency’s responsibility to make sure someone is monitoring secu- rity announcements and making the nec- essary updates.
“It’s really not about proprietary ver- sus open source,” he said. “It’s about whether or not the organization is mak- ing leadership decisions about how they’re managing risk, communicating those decisions and having the resources to adequately pursue those goals.”
Similarly, acquisition officers can com- plicate efforts because “it’s very difficult for people who don’t know open source to wrap their head around how to pro- cure something that doesn’t cost any- thing,” Cochran said.
Jones agreed. “Too often, especially in government agencies...they confuse procurement and purchasing,” he said. “The procurement process really has to start before you decide to spend money and say, ‘Hey, how do we want to acquire this? Is there something out there we can build on? In which case, we should go out to bid for the customization services. Or not bid at all because it already does what we need.’”
More broadly, Jones said, one of the biggest myths about open source is “that it’s a purely charitable activity where it’s going to cost you to do it.”
“Most of the costs that people men-
Recommended reading
Federal source code policy (M-16-21)
Office of Management and Budget
sourcecode.cio.gov
“Default to open” checklist
U.S. Digital Service
is.gd/GCN_open_USDS
Facts about publishing open-source code in government 18F
is.gd/GCN_open_18F
o4
Government agencies, of course, can be
creators as well as consumers. At the federal level, the Office of Management and Budget launched a pilot program last year that requires agencies to re- lease at least 20 percent of their custom- developed code as open-source soft- ware, and some agencies have hundreds of developers scattered among their ranks. Successfully sharing, however, requires both policy and infrastructure.
NASA, for example, has developed a suite of systems to inventory the code being created and encourage collabora- tion across the agency’s many compo- nents (see “NASA’s systems for sharing code,” Page 31). The Defense Depart- ment has long relied on Forge.mil, and in March, the Defense Digital Service unveiled an initiative dubbed Code.mil to address the licensing challenges that can complicate DOD code development.
Yet even an agency with no in-house developers can contribute to an open- source project, Jones said — and benefit from doing so.
“The simplest way is to hire contrac- tors to make modifications to the \[free and open-source software\] you are us- ing and require by contract that they publish the changes as FOSS and try to get it upstreamed,” he said.
Getting those changes incorporated into the core codebase “will help you avoid lock-in, and you get a free third- party assessment of the work quality,” Jones said. “If your contractor gets the changes upstream, then you know at
ff of selling code they already wrote.”
EMBRACE THE COLLABORATION
least one expert liked what they did.” Agencies that have in-house developer talent should encourage active involve- ment, Poole said — not only because it strengthens the code, but also because it can help with staff development and
retention.
“If you have a piece of free and open-
source software and you can contribute back to it, I think there’s no reason not to do that,” he said, although it’s impor- tant to recognize “there is a learning curve. You can make changes that are very hard to maintain and not know it. There are coding standards and practic- es that are specific to particular technol- ogies and communities. It can take some back-and-forth to learn those.”
Ultimately, though, agencies “should just do it,” Jones said. “You really have to think about free software in the same ways that we think about professional development and sharing best practices in other areas.”
For example, “when your job is to fig- ure out rural development, you don’t fig- ure out how to do rural development and then keep it secret from other agencies that are doing rural development,” he said. “When your colleagues ask you for checklists and best practices, you share
30 GCN MAY 2017 • GCN.COM
t5
Greg Elin is CEO of GovReady, a startup
company that is working to make cyber- security compliance less painful. As the Federal Communications Commission’s
hem. And it’s the same thing in IT.”
BE PREPARED TO BUST MYTHS