GovCon Expert David Egts: Help Your Defense Customers Implement Open Source Software

0

David Egtchief technologist of Red Hat North American Public Sector organization, published his latest article as part of the Executive Mosaic’s Expert GovCon program on Thursday.

GovCon Expert David Egts provided a breakdown of the impact of the COVID-19 pandemic on the digitization of federal agencies in its feature debut. In addition, he also discussed crucial lessons that government contractors should learn from these initiatives to succeed in the future.

In his latest GovCon Expert feature below, Egts discusses the three essentials to keep defense customers at the forefront as they work to implement open source software and address related technology challenges. to digital transformation.

You can read GovCon expert David Egts’ full article below:

Three things to keep in mind when helping your defense customers implement open source software

By GovCon Expert David Egts

While most of us were still refining our planning for 2022, the Department of Defense released a landmark note, Software development and open source software, establishing guidelines and expectations for the use of open source software in the DoD. Be sure to read it, as it’s filled with terms relating to risk management, licensing and costs, maintenance of open source software, and many other factors that will affect how you serve your federal clients. .

As you absorb the DoD’s position and think about how you can help it meet its open source needs, there are a few important things to keep in mind. Because while open source software has undeniable advantages, acquiring and maintaining it is not always as easy as it seems.

Free doesn’t mean what you think it means.

The word “free” has several meanings. In the case of open source software, “free” means “freedom”, not “no responsibility”. Like any other acquisition, open source software requires a long-term maintenance and upkeep commitment. In fact, the DoD cites the need for open source software to be “sufficiently supported over the life of the program.”

The DoD is looking for something akin to what it’s typically had with proprietary software, just more flexible and cost effective. This means you need a support lifecycle plan, which you will need to create, as lifecycle planning may not exist in desired upstream open source development communities. Even if they do, you may need to plan for tech updates that stretch much longer given that some missions may stretch to up to 100 years.

Non-owner does not mean no lock

The DoD memo makes some interesting observations regarding vendor lock-in. First: “Dependency on a particular software developer or vendor due to proprietary restrictions can be reduced through the use of open source software.” This makes sense, given the DoD’s desire to take a more modular open systems approach. But then: “At some point, lockdown may be likely, depending on product, architecture, or platform constraints, despite the use of open source software.”

Contrary to popular belief, organizations can get stuck when using open source software, but not in the same way that this happens with proprietary tools. For example, the source code may be open and readily available, but only a small number of contributors may know how to build it.

There is a risk of being locked in by the expertise of this limited group of developers who can move on to other areas of interest. Lock-in can also occur when an organization adapts an open-source solution with its own components, essentially shifting the burden of support and technical debt onto that organization and making the solution less compatible with the original project.

You can play a role in supporting the DoD’s preference for modular open source systems by actively participating in open source communities. Indeed, active participation is essential to ensure that communities remain vibrant and do not fall victim to the so-called ‘tragedy of the commons’.

This is where individual users with access to an open resource use that resource exclusively for their own purposes. It is better to both use the resource and contribute to it so that everyone benefits.

For your most critical open source software components that aren’t commercially available, consider a plan to develop in-house sustainment skills for people. That way, you’ll have the resources to keep the project going if communities move on before your customers are ready to move on.

This doesn’t just mean repackaging security patches and feature enhancements made by others. Instead, it means taking an active role in the project’s security plans and feature roadmap. Your active participation ensures that communities continue to create solutions that meet the needs of your government customers.

Projects are not products

Ultimately, open source projects are very different from proprietary software. There are many different facets and flavors to community open source projects, and not everything is neat and tidy. Governance is necessary, especially for open source code repositories and the developers who use them.

Developers can create applications for government use based on libraries they find in various code repositories on the Internet. But while it is convenient to extract random items from these libraries, it is not without risk, as the security hygiene of developers contributing to the libraries may be unknown. You need rigor Verification process to ensure that vulnerabilities and suspicious code are minimized.

But what differentiates open source software from proprietary software is also what makes it so special. The transparent nature of open source innovation enables vibrant communities to quickly fix bugs and security issues.

And the diversity of ideas and projects generated in these communities generates an incredible amount of innovation at breakneck speed. Ideas and projects are shared openly, allowing further development and innovation.

All of this helps to improve the quality of the software, strengthen its security, reduce costs and increase efficiency for the benefit of all involved. This is all a tough business, and you need to be very deliberate when committing to your choice to use open source software, as you would with any software acquisition.

Understand that the choices you make have potentially long-term ramifications in terms of unforeseen (and unbudgeted) security and program risks and costs. To minimize these risks and costs, partner with known and trusted organizations that understand how to do all these things so you can focus on what you do best as a systems integrator.

They can help you by ensuring that the open source solutions you provide can meet your needs for functionality, cost, maintenance, and security.

Share.

Comments are closed.