NASA has been creating code for decades and boasts more than 300 public open-source projects. The agency’s challenge is not getting buy-in for open source so much as it is managing the enthusiasm for it.
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.
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,”
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,” .... Once potential open-source solutions have been identified, ProudCity CEO Luke Fretwell said his firm offers a short checklist to gauge viability.
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.”
Embrace the collaboration
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.
Be prepared to bust myths
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.”
This really compliments some of the corporate goals i'm building out documentation for
The Open Organization Maturity Model
The Open Organization Maturity Model is a framework for helping your organization to become more transparent, inclusive, adaptable, collaborative, and communal. It outlines steps that individuals, teams, and organizations can take to critically examine their organizational practices and chart their progress toward becoming a more open organization (as outlined in the Open Organization Definition).
NASA’s systems for sharing code
https://gcn.com/articles/2017/06/30/nasa-code-sharing.aspx
How to be smart about open source
https://gcn.com/articles/2017/06/30/5-strategies-open-source.aspx
TODO Group
https://github.com/todogroup/
https://github.com/todogroup/guides
Corporate Open Source concerns
@jbjonesjr secret gist (for now)
Open Source: Theory of Operation
https://oss.kemitchell.com/
This really compliments some of the corporate goals i'm building out documentation for
The Open Organization Maturity Model
https://opensource.com/open-organization/resources/open-org-maturity-model
GitHub's Maturity Model
(internal) https://github.com/github/github-maturity-model