How to be smart about open source

Open source is everywhere in government, but many agencies still struggle with the specifics of choosing, contracting for and contributing to open-source software projects. GCN spoke with open-source advocates in government and industry, and came away with five fundamental lessons.

1. Be clear about your end goal

“The most important thing when selecting a [free and open-source] project is picking one that aligns with your business goals,” said Marc Jones, an attorney and longtime systems architect in state government. “You do not want to pick a project and then realize you now need to invest a lot of effort into modifications to meet your needs. In that respect, it is very similar to acquiring proprietary software.”

Tom Cochran, chief digital strategist and vice president for public sector at Acquia, agreed. “It would be myopic for any organization to say, ‘We’re going to default to open source for everything,’” said Cochran, who previously worked at the State Department and the White House. “Open source should be considered as part of the suite of possible solutions.... It really needs to be done on a case-by-case basis.”

CivicActions CEO Henry Poole, however, argued that open source can and should be an end goal for government. “Public funds are paying for the public good,” he said. “Having that code be publicly available, in my opinion, is the right thing to do, just from the point of view of the taxpayer.... You really want to move your acquisition strategy to paying for new technology, not paying for something that already exists.”

“At the White House, we actually did plant a flag in the ground saying, ‘It had to be open source,’” Cochran said. “Some of that was in reaction to such poor closed-source systems that we had that we didn’t want to be boxed into yet another sort of bad procurement.”

Avoiding vendor lock-in is a good reason to seriously consider open source, he added. “There’s a massive number of small and midsize companies that can do this. And if you don’t like the work or support you’re getting, you don’t have to re-platform.”

Everyone interviewed for this article agreed, however: Each open-source solution should be viewed as a potential tool, but the agency mission must drive the decision about which tool to choose.

2. Know what a healthy open-source project looks like

First make sure the software in question “is actually a free and open-source project and that all of the features you want to use are also free and open source,” said Jones, who now works at CivicActions. Especially in niche markets, companies will offer “what is known as ‘open core,’ where the base features are FOSS, but the valuable stuff that sets them apart in the market is proprietary.”

Even worse, some allegedly open-source projects carry restrictive proprietary licenses. “They simply mean that you can view the source code,” he said.

Once potential open-source solutions have been identified, ProudCity CEO Luke Fretwell said his firm offers a short checklist to gauge viability.

First, he asked, “are there maintainers who are true leaders in the community?” Brian Behlendorf and Matt Mullenweg, for example, are the highly collaborative faces of the Apache web server and WordPress, respectively. “That’s one litmus test because they are banking their personas and careers on those projects.”

Second, Fretwell asked, “is there a sustainable business that is basing its primary business model off of this product? If there is, that’s another check.”

Third is use. The “consumption side” is important — a broad user base means there’s demand for continued development — but what he looks for is the number of contributing software developers, both individuals and businesses.

Fretwell also said he checks to see whether the open-source project has “the standard aspects of any sort of industry. Does it have annual events or local communities that are engaging? Are those active?”

Poole echoed those points and stressed the need to “analyze the ecosystem around the code.”

For the web efforts for former President Barack Obama’s White House, Cochran said, Drupal was picked “largely because of the community. The bigger the support community is, that’s how you’re magnifying and amplifying your own engineering team.”

3. Pick your vendors wisely

“The first and most important thing is to have someone on staff who knows what they’re doing and what they’re talking about,” Cochran said. It’s even more important to have someone “who knows what they don’t know.”

“Honestly, it just comes down to relationships and finding the right people who can help you navigate whichever community it is you’re trying to get into,” he added.

Fretwell said a contractor’s qualifications boil down to two things: “Show me your code, [and then] how involved are you with the community?”

Any organization serious about its open-source contributions will have an active GitHub presence where that work can be examined, he added. And a firm whose employees are maintaining components of an open-source project, speaking at conferences and engaging with other contributors will have the expertise and connections to deliver for an agency.

“There’s no barrier to entry” in open source, Fretwell said. “It’s all passion and effort. So if you’re assessing a company...that’s a litmus test: How engaged are companies’ leadership and employees with those communities?”

Jones seconded the emphasis on active contributors, and he suggested looking for vendors “whose default is to mainstream the customizations” back into the open-source project — whether 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 off of selling code they already wrote.”

4. Embrace the collaboration

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 release at least 20 percent of their custom-developed code as open-source software, 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 collaboration across the agency’s many components (see “NASA’s systems for sharing code”). The Defense Department 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 contractors to make modifications to the [free and open-source software] you are using 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 least one expert liked what they did.”

Agencies that have in-house developer talent should encourage active involvement, 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 important 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 practices that are specific to particular technologies 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 figure out rural development, you don’t figure 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 them. And it’s the same thing in IT.” 

5. Be prepared to bust myths

Greg Elin is CEO of GovReady, a startup company that is working to make cybersecurity compliance less painful. As the Federal Communications Commission’s chief data officer, however, he “was a govvie who wanted to use open-source tools” — and he found himself in an uphill 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 compliance 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 accountable. And they’re unsure who’s accountable when it comes to open source.”

In truth, Elin said, proprietary software 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 security announcements and making the necessary updates.

“It’s really not about proprietary versus open source,” he said. “It’s about whether or not the organization is making leadership decisions about how they’re managing risk, communicating those decisions and having the resources to adequately pursue those goals.”

Similarly, acquisition officers can complicate efforts because “it’s very difficult for people who don’t know open source to wrap their head around how to procure something that doesn’t cost anything,” 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 mention are costs they’re already incurring,” he said, even if agency leaders don’t recognize it. “The IT folks are already bringing free software into your shop. Your IT staff is already writing software — even if they’re not software developers — that is useful not just for them but for other people.”

Furthermore, Jones said, “if they were to share that and get feedback from other IT people, it would make them better at their jobs.”