Our guest blogger, David Egts, discusses the three core elements to keep at the forefront as defense works to implement open source software and address the technological challenges involved with digital transformation.
Guest Blogger: David Egts, Chief Technologist, RedHat
This article first appeared in GovConWire.
While most of us were still refining our planning for 2022, the Department of Defense published a landmark memo, Software Development and Open Source Software, laying out guidelines and expectations for use of open source software in the DoD. Definitely read it, because it’s filled with language pertaining to risk management, licensing and costs, and the maintenance of open source software.
As you absorb the DoD’s stance, there are a few important things to keep in mind. Because while open source software has undeniable benefits, acquiring and maintaining it is not always as cut and dried as it may seem.
The word “free” has multiple meanings. In the case of open source software, “free” signifies “freedom,” not “freedom from responsibility.” Like any other acquisition, open source software requires a commitment to long-term maintenance and upkeep. In fact, the DoD cites a need for open source software to be “adequately supported over the life of the program.”
The DoD is looking for something that’s akin to what it has typically had with proprietary software–just more flexible and cost-effective. That means you need a support lifecycle plan–which you will have to create, since lifecycle planning may not exist in your desired upstream open source development communities. Even if they do, you may need to plan for technology refreshes that extend way longer given that some missions can extend to up to 100 years.
The DoD memo makes a couple of interesting observations with regards to vendor lock-in. First: “Reliance on a particular software developer or vendor due to proprietary restrictions may be reduced by the use of open source software.” This makes sense, given the DoD’s desire for a more modular open systems approach. But then: “At some point, lock-in may be likely, based on product, architecture, or platform constraints, in spite of using open source software.”
Contrary to popular belief, organizations can get locked in when using open source software, but not in the same ways this phenomenon happens with proprietary tools. For example, the source code might be open and easily available, but only a small number of contributors might know how to build it.
There’s a risk of getting locked in by the expertise of that limited group of developers who may move on to other areas of interest. Lock in can also happen when an organization adapts an open source solution with its own components, essentially shifting the burden of support and technical debt on that organization and making the solution less compatible with the original project.
To best support modular open source systems, actively participate in open source communities. Indeed, active participation is essential to ensure the communities remain vibrant and don’t fall victim to something known as “the tragedy of the commons.”
This is where individual users with access to an open resource use that resource exclusively for their own ends. It’s better to both use the resource and contribute to it so everyone benefits.
For your most critical open source software components that aren’t commercially available, consider a plan to build in-house sustainment skills for people. This way, you’ll have the resources to maintain the project if the communities move onto something else.
This doesn’t mean simply repackaging security fixes and feature enhancements made by others. Instead, it means playing an active role in the project’s security plans and feature roadmap. Your active participation ensures the communities are continuing to create solutions that meet the needs of government.
At the end of the day, open source projects are very different from proprietary software. There are many different facets and flavors to community open source projects, and it’s not all neat and tidy. Governance is required, particularly for open source code repositories and the developers that use them.
Developers may build applications for government use based on libraries they find in various code repositories on the Internet. But while pulling random pieces from these libraries is convenient, it’s not without risk, as the security hygiene of the developers contributing to the libraries may be unknown. You need a rigorous verification process to ensure vulnerabilities and suspicious code are minimized.
But what makes open source software different from proprietary software is also what makes it so special. The transparent nature of open source innovation facilitates vibrant communities to fix bugs and security issues quickly.
And the diversity of ideas and projects being generated in these communities is driving an incredible amount of innovation at a breakneck speed. Ideas and projects are being openly shared, allowing for further development and innovation.
All of this is helping to improve the quality of the software, harden its security, decrease costs, and increase efficiency for the benefit of all those who participate. All of this is a challenging undertaking, and you must be very deliberate when committing to your choice to use open source software, just as you would with any software acquisition.
Understand that the choices made have potentially long-term ramifications in terms of unanticipated (and unbudgeted) security and program risks and costs. To minimize these risks and costs, partner with known, trusted organizations that understand how to do all of these things to best meet your feature, cost, maintenance, and security needs.