Commentary

Dispelling myths in the federal use of open source software

Technology modernization is a national priority and is only possible through adoption of cloud native technologies.

Justin Razmic

February 25, 2022 1:51 pm

5 min read

Technology modernization is a national priority and is only possible through adoption of cloud
native technologies. The pandemic accelerated this trend, particularly in the private sector,
which readily embraced the idea of distributed workforces, but the government is not far behind.
As more entities realize the benefits of cloud native technologies — security, reliability, cost
reduction and flexibility — it becomes more commonplace.

And it’s critical to understand that there cannot be a conversation about building and deploying
applications on cloud native technologies without also considering open source software (OSS),
since OSS components often function as the building blocks of these technologies.

In 2016, the Obama administration introduced a Federal Source Code Policy, establishing a
standard for and supporting OSS, touting the collaborative benefits. The policy includes “a pilot
program that requires agencies, when commissioning new custom software, to release at least
20% of new custom-developed code as open source for three years.”

There are highly varying levels of compliance with the policy across the government. Some
agencies are fully compliant with the policy, such as the departments of Energy and
Transportation, NASA, and the General Services Administration. Others are partially compliant,
and some are non-compliant.

Recognizing that taking a new approach to technology implementation always comes with new
boxes to check and learning curves, addressing a few myths about open source will increase
understanding as the government continues to prioritize it.

Myth #1: OSS comes with more risk than proprietary software.

Historically, much of the criticism about OSS relates to the open nature of the source code and
perceived lack of support in maintaining it. The assumption has been that this puts an
organization at risk, both from potential vulnerabilities and software bugs. However, any time an
organization implements a new tool, either open source or proprietary, rather than developing it
in-house, it is accepting a certain level of risk.

Just in the past year, major vulnerabilities in proprietary software have had catastrophic effects
across commercial and government organizations alike. Malicious actors go to great lengths to
compromise applications and cloud systems, whether the source code is publicly available or
not. This is why implementing security best practices, such as vulnerability management,
access control enforcement and network security is ideal. To secure cloud native applications,
many agencies are moving to a DevSecOps model that focuses on integrating security practices
— like vulnerability management — into the development and deployment phases.

There are also many tools that help with every part of the vetting process, such as scanning
code and Docker container images to check for vulnerabilities. Many of these vulnerability
scanners can integrate with current tech stacks and can be implemented quickly.

As OSS adoption has gained steam in recent years, it has fostered greater collaboration and
support for open source projects. Many have substantial communities providing financial support, contributing code, and helping to identify and resolve software vulnerabilities and bugs.

It is not uncommon to see OSS projects running bounty programs to ensure issues with code are found and fixed quickly. In other cases, open source projects are maintained primarily by commercial entities that invest significant time and resources into maintaining the software just as they do their proprietary products.

In 2016, the General Services Administration launched Code.gov, a government-supported
GitHub-style repository that enables government agencies to take advantage of OSS. The
platform helps agency partners and developers reduce code spend and increase software
quality by promoting code reuse and educating and connecting the open source community.
This effort continues to have an impact on the use of OSS across sectors by encouraging its
use and driving greater innovation in government software.

Myth #2: Open source isn’t mature.

Open source has been in existence longer than many realize. The concept of publicly available
and usable code was termed “open source” in 1998 when the trademark process began. Often,
open source projects receive frequent contributions, thanks to the growing OSS developer
community. The more active an open source community, and the larger it is, the more mature
the community projects will be. Similarly, the more that open source is used commercially, the
more mature it becomes. Open source projects backed by knowledgeable maintainers or
companies with a vested interest come with an expected level of quality and dedication of
resources. Ample deployment in the private sector has allowed these maintainers to hone
valuable features and build robust tools that serve a variety of needs, and public sector
organizations can benefit from this maturity.

Myth #3: Open source is for enterprise only, not the government.

While it is true that many of the leaders in OSS hail from major enterprises and innovators, such
as Google or Facebook, open source is not just for the private sector. There are many benefits
to government use, and there are many government-backed open source initiatives. OSS can
be a value-add for the federal government because its open nature allows it to be shared and
reused across agencies, which is important for collaboration as well as budgetary
considerations. Without the need for significant monetary investment, and with taxpayer dollars
at stake, open source is a financially responsible solution. The opportunity to work with
innovative, open source software and tools can also be appealing to developers, which helps
with recruitment efforts in an already challenging talent market.

Because the nature of OSS is collaborative, most software is built to integrate with other tools in
the broader ecosystem. This provides flexibility across the stack and allows agencies to build a
stack based on tools that fit very specific needs.

There are many open source initiatives already in the federal government. GSA’s open source
policy includes GSA’s in-house 18F team dedicated to digital solutions as a resource that
promotes the use of open source software, helping both civilian and military agencies. And the
aforementioned Code.gov includes tutorials for how to procure software and how to inventory
code.

As the federal administration continues to advance modernization through cloud native
technologies, open source will be key to success. Agencies should overcome misconceptions in

order to take advantage of the benefits that OSS offers. As a result, government IT departments

embracing transformation find themselves on an innovative path to execute on their missions in
the most effective way possible.

Justin Razmic is a federal account manager at Aqua Security.

Dispelling myths in the federal use of open source software

Myth #1: OSS comes with more risk than proprietary software.

Myth #2: Open source isn’t mature.

Myth #3: Open source is for enterprise only, not the government.

Related Stories

When it comes to open source, culture continues to eat strategy, policy for lunch

Improving cybersecurity with open source software

Open source: An efficient way to handle data

Related Stories

Top Stories